IETF sunset4 working group meeting notes Monday, 30 July 2012 Vancouver, Canada ==================================================== Meeting summary ==================================================== A change to the charter was discussed. Further changes will be required to reach wg consensus. The main controversial issue is about the inclusion of CGN and other IPv4 life support work into the milestones of the charter. A possible solution that was raised is to restrict the scope to scenarios where IPv6 is deployed, but requires some work on the IPv4 side to continue reaching the non-converted IPv4 Internet. draft-george-ipv6-support, which is the reference to the sunset4 direction, has been discussed but did not get consensus to be adopted in the working group. Possible candidates would be other working groups such as intarea, AD sponsored or IAB. The IAB IP evolution will look to see if it may take on this work. A comment was made that it would be better to use the normal IETF process (wg consensus, LC, IESG,. …) than the IAB stream. Documents on gap analysis, a milestone already in the current charter, have been discussed. draft-dionne-sunset4-v4gapanalysis has seen unanimity to have this work done in the wg. draft-perreault-sunset4-noipv4 has been discussed and found strong support for being worked in the wg. However, it is currently not a milestone in the charter but in the new proposed charter. draft-ietf-v6ops-464xlat has been presented but is currently a v6ops document. The chairs of the v6ops, sunset4 and respective AD will discuss which wg it should land. Marc&Wesley, co-chairs, sunset4 Below is extracted and lightly edited from the jabber log. ==================================================== Charter discussion, Chairs ==================================================== page 7: "What is sunset4"? …and "What Sunset4 *isn't*" Alain Durand: does this slide apply to today's meeting? Wes: Not necessarily … this agenda is a little open because it is the first meeting wg chairs - what sunset4 ISN'T the charter is normative. there is one current, and we are going to talk about the new charter. Discussion of changes to charter. Alain: what "does not harm or delay the deployment of IPv6" mean. Wes, Marc - looking for WG consensus about what to adopt. Alain: What about "is this useful" Wes: does "widespread demand" imply useful? Mark Townsley: WG didn't write the charter, a handful of people did. Wes: we are now making transition to WG control of operation. Dave Thaler: exact wording up to IESG; last change is an improvement and addresses his previous concern Alain: big question is how much maintenance on IPv4? not measured on technical basis. Lee Howard: rules might not be clear; comfortable with "building the airplane in flight" Peter Lothberg: is speeding the transition in or out? Wes: lots of WGs already doing transition. Page 2 of charter changes Change is intended to open the scope a little. Phillip Matthews: Read like we take all IPv4 work out of other WGs and put it here. Marc: That's not what sunset4 will do. Ralph: Not everything IPv4-only comes to sunset4; work-in-progress doesn't come to sunset4 Alain: is there a conflict between earlier slide and this charter change? Wes: no … we are being pragmatic to minimize work on IPv4 but recognize that we can't just stop immediately. Alain: does a new DHCPv4 option come here? Does softwires and behave work come here? Wes: not pulling work out of other WGs. Mark Townsley: objects strongly to waffle-words in the charter Dave Thaler: What chairs propose is that behave is on a path to close down; "issues that arise when you turn off IPv4" (which was not addressed in behave), such as inter-subscriber fairness. Alain: advises against "kitchen sink charter" Mark: Ralph's "no IPv4 service" and Mark's "how to get to IPv4 when IPv4 is being turned off" are interesting and clear things to do. Wes: encourage those with strong opinions to propose new text. Dave Thaler: like the three milestones; what status? Alain: defining how a vendor changes a mapping table is out of scope (1st milestone) Marc: will not take consensus cal on charter now; summarized changes; will continue with current charter until changes are agreed upon. ==================================================== draft-george-ipv6-support, Lee Howard ==================================================== slide 3 over-baked, now burnt slide 5 - salient points slide 6 - adopt as WG doc? Alain: if this WG focuses on turning off IPv4, this WG doesn't need this document Mark: have the IAB publish this document Wes (as co-author): 2nd presentation - no feedback from intarea; IAB should have written it but didn't Alain: this WG should not replace IAB MArk: could still be co-authors if from IAB Dave: request should go to IAB program Dave Thaler: IETF stream demonstrates broader consensus Joel Jaegli: need to be "baked/basted" in a WG Marc: consensus call - appropriate for IETF (unanimous) Marc: consensus call - here, IAB, intarea? Jari Arkko: prefers a WG. prefers a WG no consensus; not much support for "here" ==================================================== draft-dionne-sunset4-v4gapanalysis, Simon Perreault ==================================================== What problems will result from turning off IPv4? Category 1: indicating that IPv4 connectivity is unavailable Category 2: disabling IPv4 in the LAN Joel Jaegli: is IPv4 link-local address really a bad thing? Peter Lothberg: How does internet work on IPv6-only? Stuart Cheshire: parallel problem in moving from AppleTalk to IPv4; eventually all the AppleTalk devices timed out. Chris: difference between neutral to IPv4 and antagonistic to IPv4 slide 9 - many subtle dependencies on IPv4 in OS and apps Alain: is "unmodified IPv4 host" a constrain Simon (presenter): just doing analysis here; no solutions slide 12 - Bjoern Zeeb has developed FreeBSD w/o IPv4 Mark: look how many interesting things to do here! Dave Thaler: Might be categorized as "protocol work", "recommendations to implementors", etc. slide 13 Lee Howard: it is good work; would be appropriate to adopt as WG work item - three questions have been answered; Erik Nygren: *security* is a pervasive issue Wes: work on turning off IPv4 has consensus adopt? yes: unanimous. to be confirmed ==================================================== draft-zhou-sunset4-scenarios, Cathy Zhou ==================================================== slide 6 - enterprise site it is for the work item in previous version of sunset4 charter Phillip Matthews: different from previous presentation; what is the focus? Cathy (presenter): identify gaps for sunsetting Phillip: how does it differ? Cathy: considering to merge with pervious draft Phillip: a single draft here? Wes, Cathy: mainly a CGN scenarios document Lee Howard: CGN gap analysis document; doesn't successfully answer three questions No call for adoption; give authors an opportunity to revise or perhaps merge with pervious doc ==================================================== draft-perreault-sunset4-noipv4, Simon Perreault ==================================================== to eliminate IPv4 (turn off IPv4), must carry indication over IPv6 slide 8 - v4-level Mark Townsley: what it means to have types of addresses is interesting, and then not having such addresses is interesting Regarding options … home network is not the pressing issue; the SP network is. if someone can please relay to mic - I think there is an important problem of shutting down useless DHCPv4 activity on networks where IPv4 is not deployed, but there seem to be additional complexity in the draft which addresses more than that. I'm not sure that rest is needed - just a simple way to say "no DHCPv4 here" I think would address the most important problem Simon: this document explicitly addresses SP and CPE upstream interface slide 12 Michael Richardson: turns off IPv4 on upstream interface, not on other interfaces Chris Liile. : level 1 wasn't clear that no-IPv4 applies only to upstream interface level 2 - turns off all IPv4 both upstream and downstream …can lead to dueling SPs Stuart: we need to be able to turn off (or at least down) DISCOVER traffic; reaching into the home to turn off IPv4 may be inaapropriate Dave Thaler: problem for hosts - keep trying IPv4 if no response, to avoid load on host Dave: a host may use IPv4 internally, with no network traffic ALain: not necessary to use DHCPv6 Alain: what about IPv4-over-IPv6? Problem is more complicated than suggested in this document. Have you guys concluded the WG yet? I thought the only reason to open it was to close it again immediately and be done with the stuff. Phillip Matthews: not convinced we need more than "go to DHCPv4 at a much lower rate". Simon: not a bandwidth problem Phillip: than what is the problem? Wes: bandwidth can be a problem because of aggregated traffic … DHCPv4 server has resource limitations, as well Mark: may turn off IPv4 incrementally, so some clients should be assigned addresses, and some should not … so can't just turn off relay agent Jari: agrees with comments about "what is the problem": protect DHCPv4 servers, protect clients from wasting IPv4 connections …assumes "someone knows" and is trying to manage devices inappropriately Wes: is WG interested (although too early for formal adoption) and asking for substantial review unanimous that this is useful work ==================================================== draft-ietf-v6ops-464xlat, Cameron Byrne ==================================================== Cameron Byrne: here at request of chairs, not WG shopping slide 7 Joel Jaegli: discussion still at mercy of int and ops area ADs Alain, Mark: stay in v6ops Michael Richardson: who is responsible for NAT64 pcp gap? Alain: "just like" DS-lite except with translation; pcp WG is the place for the work Wes: asks for reveiw of other CGN optimization docs.