SUNSET4 Working group Meeting IETF90, Toronto Canadian Room. 2014-07-24 17:30 Agenda: Agenda Bashing & Administrivia -- Chairs Current document status -- Chairs Turning off IPv4 Using DHCPv6 or Router Advertisements -- Simon Perreault draft-ietf-sunset4-noipv4 IPv6 Support Within IETF work -- Lee Howard draft-george-ipv6-support-02 Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses - Gang Chen draft-chen-sunset4-cgn-port-allocation-04 Managing Router Identifiers during IPv4 Sunset -- Peng Fan draft-fan-sunset4-router-id-00 ==================== Agenda agreed. Turning off IPv4 Using DHCPv6 or Router Advertisements -- Simon Perreault draft-ietf-sunset4-noipv4 * a lot of negative feedback, some of which was actionable. * added a lifetime for no-IPv4 option, same as configuration mechanism. * unanimity requirement * can selectively enable v4 via DHCPv6 * other issues: what problem is being solved.... real problem is DHCPv4, not killing IPv4. * "should not be done with v6" * generalizations: full stop, unnecessary, might be useful..but. * discussion: Lorenzo: draft needs to be more precise on timing "are" "is present" etc, not descriptive enough - multiple asynchronous protocols, hard to define Simon: is this fixable, or is this unaminity not possible Lorenzo: complex Dan york: were there any alternatives suggested? simon: not really, implementing over Dhcpv4 Lorenzo: debate was acrimonious, people belived what you were doing was wrong, that they were not being listened to. I strongly believe it's a terrible idea to do this on RA, because everyhting without RA guard is exposed. definitely should solve this problem Lorenzo: thinks it needs to go into DHCPv4 is a must. Ted: if you try to do it as a vote, you still have to do it in DHCPv4. susceptible to an attack if you allow any source ot override Andrew yourtchenko: maybe not an ipv6-only network but also NAT64, etc. when you discover this, then maybe there's no IPv4, but no explicit signaling needed? erik: was there discussion about making a recommendation that a network can block v4 at the lower layer? simon - yes, gap analysis, exists Bernie Volz: like dhcpv6 - change timeout for retrans, change autoconfig v4 lln from true to false if you have v6, not autoconf LL v4 if you have v6 - reduce noise from periodic DISCOVER this could trickle down into the home... Ted: presumption is that you'll get IPv4 when you connect. only reason to do that when device is powered on is that you want local network to work when you don't have WAN Can do bonjour over Ip6, filesharing, etc. don't necessarily need IPV4 LAN before you get WAN. should default behavior still be to issue IPv4 addresses? Transition advice, not enforceable. process - WG should come up with the good solution and attempt to publish. not WG's job to figure out IETF consensus, just WG consensus. Dave Thaler - support. I disagree that if the ISP is IPv6-only, you want the home to be IPv6 only. Also disagree with "ok to have IPV6-only home" -- not yet. I'd like to see it, but that's not today. Ted - heuristic to address the objection: if you get a dhcpv4 discover, send router solicit Michael richardson - people aren't sure where/when this is going to be used, by whom - need a clear applicabiliy scope from people who want to use this, rather than assuming it'll be on everywhere. The real problem with IPv4 in the home isn't that it exists, it's the default route to cause the host to think they have connectivity, when they don't. Autoconf 169 addresses works for printers, nothing broken there. Eric vyncke - get it on dhcpv4 as well, currently binary - IPv4 yes or no, need a middle ground Dave Thaler - default route - how many v4-only printers actually support IPv4 LLN? I suspect not, so can't just say use ipv4 link local. Also, not easy to tell hosts non-link-local address now and default route later when WAN link comes up. Lorenzo: we can resolve if we limit scope. defining a hint that admin can use, host can ignore. you cannot put this in IPv6, because you're exposing millions of hosts to drive-by damage. has to be in IPv4. We will not advance otherwise. people have issues with normative lang. IPv6 Support Within IETF work -- Lee Howard draft-george-ipv6-support-02 * "motherhood and apple pie" * Should we split the gap analysis section and add into the existing gap analysis doc? * What to do further with the document Ted Lemon: Discussion occured in softwires couple of sessions ago, about dhcp protocol used for tracking the leases; TCP-based; the document does not say you should listen on both AFs, and implementors might forget to listen on the diff AF. Wonder if other cases like that. Lee Howard: I think we have covered from where it is. Ted: The situation was completely agnostic from the AF standpoint but someone might misunderstand. The protocol to track leases - TCP-based, management protocol. We have the ability to transfer dhcpv4 over v6 network, might not have a way to do leasequery over v6 network Lee: If it just said this is the protocol handshake, might not include listening on the other protocol... not sure how to make it clear to that implementor Ted: you should make the code listen on v6 if host supports Lee: easy to add Wes: there's a gap analysis and an existing WG doc; this is making a meta point that we need to go and look at the new things, and we need to do the work to do that. Lee: 6540 probably covers that particular case. Marc Blanchet: part of this draft is about IETF policy; some people around here were discussing whats the process to do that, where are we about that; Lee: we had a clear feedback last meeting - the broader consensus we can establish, the stronger the document. So if we can get wider advice from various groups, to be able to demonstrate (to IESG) - this is the help we are looking for Marc: the current section looks like it woul dbe BCP Lee: Reasonable suggestion Lorenzo: the IETF must this, that. The ietf who ? That's completely impossible to implenent Lee: can put in the passive voice Lorenzo: still imopssible. I am in favor of separating the gap analusis part; taking hte time to review everything that can be broken is not good use of time. We should converge on the sense of principles applying to work from now on - "thou shall not do v4-only unless ... ". Normally in the organizations you require hard-to-obtain approval, dont know how to do it in the IETF. That's what should be in this document - the gap analysis is not a good use of the time. Lots of work nobody wants to do. Wes: that's why isoc paid someone to review and publish the documents Lee: there are principles... should be a documented consensus of the working group for ipv4 work... Lorenzo: I could not easily see from the reading the document/ Ted: suppose this became bcp, we said ietf does not do bla; then it is IESG responsibility to point out to the charter. The way this would happen IESG would become aware of this BCP; during the IESG review process as well = for cases i described IESG review is a good place to catch that. This never occured to me until discussion in the wg came today. Advice to IESG since it acts as a gatekeeper; but also advice to ietf. If someone acts in the mailing list, they might say "what about bcp ...." Else Lorenzo is right who is responsible and how is it going to happen. Simon: I want to point the gap analysis draft and the ... you proposing. When we started, we started to enumerate the problems people experience when they live in ipv6only world and want to turn off ipv4. It is not the type of "I am missing a feature" Wes: we are not suggesting doing the exhaustive analsysis, suggesting to do exaustive analyusis Simon: i standby - dont think it is useful Marc: I think we need to split this document. Lorenzo: I will be happy if you take out section 3 or move it to a different document. Jeff Houston: I agree with Lorenzo - if you move forward, section 3 unrealistic. Section 4 should be rephrased - if you are talking about the IETF/ or IESG gating workg make it clear. Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses - Chris Donley draft-chen-sunset4-cgn-port-allocation-04 * new * goal to address charter item to describe port allocation methods. * Cablelabs has IPR on deterministic logging Wes: IPR needs to be updated to point to this draft, currently does not do so. * Think document is in shape for WG adoption, would like to ask for adoption Lorenzo: as software engineer who needs to write some code, when he sees a patent he starts running away. I wonder if by publishing guidance that is encumbered by IPR we are making things worse. I can see why you would publish IETF doc with IPR for interop; but this is not - and I feel by having it there is a mine an implementer would trapped by it. No doubts it is useful work but i dont want to read just in case i ever stray in the area. Chris: deterministic logging was available for long time, the basic idea do not sue us we would not sue you. At the time there were a lot of people doing that work in that space, and we wanted to make it available to the community, so we protected the IPR from cable labs. Wes: this is not the only thing discussed in the document, and there are other methods Lorenzo: if this is minor part of the document, can we publish it elsewhere and refer to it. I have to be careful what i read as soon as i hit IPR I have to punt it to the lawyer. If the IPR could be excised to simply a pointer in the references, I would be much comfortable reading this document. Chris: this was what we had in version 3 - and the guidance was to bring it in. Wes: we will take the remaining discussion to the list; the problem was there were multiple drafts; might be ok to break this section out but would like to get feedback from the folks on the list. Managing Router Identifiers during IPv4 Sunset -- Peng Fan draft-fan-sunset4-router-id-00 * originally router ID is a 32 bit number <~~> IPv4 address. * this breaks in IPv6-only network. * several possible ways to generate * requesting review Wes: GROW and routing area lists need to be aware of this document, please send to the lists. ----