IETF97 Sunset4 Working group Meeting Thursday November 17th 2016 11:10-12:10 Seoul time Session was chaired by Eric Vyncke - admin, 5 min, Chair Chair reviewed WG status. - IETF: End work on IPv4, draft-howard-ipv6-ietf, Lee Howard, 45 min. Slides: https://www.ietf.org/proceedings/97/slides/slides-97-sunset4-ietf-end-work-on-ipv4-00.pptx Lee reviewed the action items from the last meeting. IAB statement to SDOs on IPv6 - done IESG statement on resisting IPv4 work - suggested getting an IET consensus statement on it - hence back here today ID-nits done in BA Cleaning up IPv4 literals - need to do Running IETF SSID as NAT64 by default - John Brzozowski supported it - many hands in room raised when asked if using it - Lee encouraged more people to use it - possible issue with Skype Mark Andrews: is NAT64 the right thing to use? David Schinazi: NAT64 is de facto one being used by network operators; just pick one and move on Mark: So too is DS-Lite, MAP and other things; NAT64 has issues that others do not have, and provides no benefit David: But it's being used by operators Lee: DS-Lite is being used too Jordi: Define what our goal is - break things or allow people to work? We can log things and help vendors by pointing out issues via an intermediate stage. Jen: People can use default SSID with NAT64. If there is a problem they fallback to the dualstack SSID. Lee ran through the proposed "IETF consensus" statement for ending work on IPv4 as described in draft-howard-ipv6-ietf-00. Chris Bowers: Would like to see some wording to allow IESG when evaluating charters to include the actual impact, perhaps on applications rather than routing protocols, e.g. OSPF & IS-IS IDs. Feels it would be OK to have an exemption for things that are deemed a waster of effort, e.g. the ID is a v4 address, doesn't NEED to be a v6 one. Aaron Hughes: Add a timeline to the proposal. Likely to be a lot of RFC updates to have full IPv6-only specs. Lee: Please forward. Aaron: Happy to help. David: What about new work that CAN be dual-stack? e.g. homenet is v6-centric, not v6 only. Lee: Believes this is covered (see Statement 3/4 slide). Tim Chown: Also consider whether doing something best for v6 only somehow breaks v4 - does that matter? :) Pierre Pfister: Homenet charter and work approach is correctly covered by the proposed text: i.e. support IPv4 but do not extend IPv4. John Scudder: Don't really care if it goes in or not. Lee: Want to allow IESG to have a club to hit such new proposals with. Chris Bowers: Suggest priortise what we're working on - router IDs are low priority. Lee: Not about rooting out such things - doc is about new work. Chris: In terms of impact, networks that are running v6 only, with OSPFv3, may still have OSPFv2 running as well. Lee: Not said we're stopping work on OSPFv2. Chris: Shall I propose some wording? Lee: I'd like more feedback. Current view is EVENTUALLY we'd stop using OSPFv2. Mikael A: If you propose a new OSPF LSA won't that be for both OSPFv2 and v3? Chris: Yes, but different encodings. Chris: MPLS right now not done over OSPFv3, in practice. Would need paraellel OSPFv3 version. OSPFv2 might then be for MPLS, and only use a small number of v4 addresses. Mikael: Is there anything I can only do in OSPFv2 and not v3? Chris: There are gaps Mikael: When will they be fixed? Chris: I don't know. But what is the impact on just the existence of IPv4 addresses on links in your network? That's the important thing. Mikael: Why do I have to configure IPv4 to run MPLS? Eric Hughes: The draft implies we do OSPFv4; get rid of v4 IDs... Lee: Need to be sure our protocols can run v6 only. OSPFv2 is something of a special case. Say that router IDs are not IP addresses. Simpler way out. It's interfaces that matter, not just router ID. Different things. Alvaro Retana: Need some wordsmithing around "vital operational issues". Clarify what is really new IETF work. Lee: Does this mean we focus on Charters, or IESG can act on anything? David: All the above. Lee: Serious if routing AD says we can't work on OSPV2. There are repercussions of that. What we say in this draft will affect length of IETF Last Call. Mikael: Needs to at least be feature parity; a new OSPFv2 feature must be done in OSPFv3 as well (for example). Lee: Maybe say "No feature can be added that's IPv4-only unless there's an equivalent feature added in the IPv6 version." Eric V: Does draft fit the Charter? Lee: covered under advice. AD? Terry M (AD): It is "provide recommendations", so yes it fits the charter. Chris: Can you clarify what IETF consensus is? Terry: WGLC, IETF LC then IESG Ballot, then published. Lee gave idea of timeline, involving mail list discussion, etc. Eric: Does WG want to adopt document? Humm. Yes - quite loud No - silence Eric: Clear adoption agreed. (Confirm on list?) - Let 'localhost' be localhost, draft-west-let-localhost-be-localhost, Emily Stark (for Mike West), ~10 min. [slides not in meeting materials area?] Raised by RFC 6761 Behaviour results in proliferation of IP address literals in applications - bad. in W3C-land, developers want to test secure context features on localhost. Proposal removes need for use of literals that would make killing off IPv4 harder. Allows localhost to be used for security decisions. Dan York: Did this go to dnsop Emily: I don't know. Dan: Mike should take this to dnsop; clearly operational; lots of 'fun' with RFC6761 there already. A meeting is planned on it,we could add this. Peter Koch: 6761-aside, localhost resolution discussion is decades old. Not sure how reliable result is meant to be. SHOULD to MUST may not mean existing implementations actully get changed. Queries to localhost may leak to root servers today. What really want is authorittaive service to repsond with whatever result you desire. Can't assume that's happening any time soon. Emily: This ended up here due to proliferation of literals; let's remove the cause of that. And yes changing an RFC may not mean implementations change, but in secure context text acknowledge state of the world. Peter: Seems you are looking for a justification to do something. Emily: Makes sense to do this change in parallel, as it suprises people. Peter: I'll continue offline. Eric: AD - where should we do this work? Terry (AD): Will talk to Joel who is responsible AD for dnsop Joel: Will need to be discussed in dnsop. Doesn't HAVE to be advanced there. David: (channeling Stuart Cheshire) - Stuart supports this. Sessioned ended 12:00.