6MAN Working Group, Seoul IETF Meeting Tuesday 15 November 2016 10:00-12:30, Grand Ballroom 2 Chairs: Bob Hinden, Ole Troan Minute taker: Eric Vyncke Jabber Scribe: Mikael Abrahamsson Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf97/6man ----------------------------------------------------------------------- ----------------------------------------------------------------------- Agenda Introduction, Agenda Bashing, Document Status, Chairs, 15 min. Working Group Drafts IPv6 Specifications to Internet Standard, draft-ietf-6man-rfc2460bis , draft-ietf-6man-rfc4291bis , draft-ietf-6man-rfc1981bis , Bob Hinden, 40 min. IPv6 Neighbor Discovery Optional RS/RA Refresh, draft-ietf-6man-rs-refresh , Erik Nordmark, 15 min. Active Individual Drafts IPv6 Router Advertisement Prefix Information Option, draft-pioxfolks-6man-pio-exclusive-bit , Erik Kline, 15 min. IPv6 Node Requirements, draft-clw-rfc6434-bis-00 , Tim Chown, 15 min. Candidate encapsulation for BIER, draft-pfister-bier-over-ipv6 , Pierre Pfister, 15 min. New Individual Drafts Netmod: IPv6 RA submodule options ?, draft-ietf-netmod-routing-cfg , Tim Chown, 10 min. ----------------------------------------------------------------------- ----------------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 15 min. -------------------------------------------------------------- Suresh: the IIDS is already in the IESG queue IPv6 Specifications to Internet Standard, draft-ietf-6man-rfc2460bis , draft-ietf-6man-rfc4291bis , draft-ietf-6man-rfc1981bis , Bob Hinden, 40 min. ------------------------------------------------------------------------- RFC 2460, 4291 and 1981 are being updated. RFC 2596, 4443 are ready to advance. ... slides same as before. Unclear from 2-steo RFC6410, how to deal with updates, so incorporating updates (plan presented at IETF93) Dave Thaler: RFC 4291 is reference in IANA considerations, in short we will need to double check this reference (in the RFC editor section) and put them in past tense. [Note, verified that RFC editor will do this after IANA considerations are processed by IANA, no change to drafts required.] Dave Thaler: why adding Routing Header is added back to the list for full implementation? Because it was in RFC 2460, then removed and added back because there are other type than deprecated RH-0. Dave Thaler: is a an editorial change for point 7) (ICMP sent when fragmentation), Bob: yes. Tim Winter: no implementation are sending ICMP anyway. Tim Chown: it was prone to misinterpretation and now the text is clear. Regarding inserting extension header en route, Bob run a on-line survey with choices: ban, describe the problems, say nothing more. 57 responses from the WG with 53 in favor of simply describing the problem (also confirmed by a 'condorcet calculator'). Fernando Gont: why describing the problem when it was forbidden before? Bob: it was a little unclear in the original document on whether it is forbidden or not. The WG should write an I-D on the potential problems. Suresh: it was unclear in the RFC 2460 Mark Townsley: what matters is not what Bob thought years ago but what is working on the Internet. Fernando: so writing a piece of code which violates standard will change the standard? Bob: the consensus of the WG is clear. Suresh: the standard was unclear and ambiguous. JJB: we will probably never agree on original document, let's describe the issues (and possibly the use case) Lorenzo Coliti: I support the text even if the original text was clearly forbidding ext header insertion. Suresh: original clearly does not use RFC 2119 vocabulary Tim Chown: we should also update the section on header processing as actual behavior on the Internet is different than in the original document. Lorenzo Colitti: we do have now experience Stefano Previdi: I agree with the consensus, the proposed text is also OK. Either with do have experience or not. In the latter, then do not say anything on the topic. Regarding SRH does not recommend header insertion but rather encapsulation. Stefano will be happy to extend the SRH I-D to include header insertion. Jen Linkova: we do have experience with device processing ext headers, this is called ACL Mark Townsley: also agree with the proposed text Dave Thaler: the text issue with AH is only applicable when the inserted extension header is part of AH coverage. Ole Troan: the packet size if included in the AH coverage. Dave: OK, I change my mind Tom Herbert: the text works as it warns about some issues Tim Chown: proposed some changes in the proposed text to make it clearer "and breaking Path MTU Discovery, which can result in ICMP error messages being sent to the source of the packet, rather than the node that inserted the header." David Moses: ?. Bob Hinden: some extension headers allow for change in their content. Ole Troan: we will make it clear to the IESG that this was a rough consensus and that we will not talk anymore about this issue. IPv6 Neighbor Discovery Optional RS/RA Refresh, draft-ietf-6man-rs-refresh , Erik Nordmark, 15 min. ------------------------------------------------------------------------- Erik explains again the content of his I-D as it lacks reviews. It includes adding a new option 'RA refresh' to assist sleeping nodes and specify a SHOULD reply with unicast RA when receiving a unicast RS. Dave Thaler: what is the relationship between router refresh & router lifetime? Erik: adding clarification text will be added. Suresh: there is another I-D relaxing the max value of router lifetime Lorenzo Coliti: if we loose resilient RS, then we are dead. RFC 7772 already includes a SHOULD for replying unicast RA on some network. Forcing the router to remember which host uses this refresh time is lossy and will lead to errors especially when legacy host misses the RS/RA (as mcast RA are not sent). Erik Nordmark: the context is not about power saving mode but really nodes which are sleeping. Michael Richardson: if an address disappears from the NDP cache, then it simply means that we didn't talk to it but not that the addressed has disappeared. Lorenzo Coliti: we have now devices that can filter too frequent RA Michael Richardson: thinking about adding the mcast RA into the WiFi mcast beacon to solve some mcast 'waste'. Suresh: getting a sequence number in RA (to detect changes) would be nice. Erik Nordmark: so removing the R-flag in RS is probably the solution to all problems indicated by Lorenzo & co. Ole Troan: should move the discussion to the mailing list and let's have a discussion with Erik, MCR, Lorenzo and Suresh. IPv6 Router Advertisement Prefix Information Option, draft-pioxfolks-6man-pio-exclusive-bit , Erik Kline, 15 min. ------------------------------------------------------------------------- Presented by Mikael Abrahamsson. If a node receives a /64 and if the host knows about it, then there is no need to do DAD/ND within this prefix and other optimizations. The host could learn this by having a X bit in PIO for 'exclusive use'. Issues include keeping some states in the router (same as DHCP PD), SAVI. Erik Nordmark: how can we remove the state in the router? Mikael: the state will have the same lifetime as the prefix (should probably author a V60PS I-D on how to do it). Lorenzo Coliti: state handling is a very complex problem => should restrict this option only to data-link where the layer-2 can indicate that there is only one node (such as 3GPP, PPPoE, ...). And we could also link the prefix to a MAC address/subinterface rather than to MAC address & LLA. Erik Nordmark: restricting use case is good but not always applicable (WiFi the layer-2 and layer-3 nodes are not always collocated). James Woodyatt: changing MAC address is not only for privacy reason but also for sleep proxy. Alex Petrescu: public hotspots do not use WPA so they cannot use this technique. IPv6 Node Requirements, draft-clw-rfc6434-bis-00 , Tim Chown, 15 min. ------------------------------------------------------------------------- RFC 6434 is kind of old, dated 2011 and now we have more deployment experience. Alex Pretescu: keep the section on host mobility because we use it (even if you can de-emphasize it) Lorenzo Coliti: happy eyeball is not an IPv6 requirement but more to allow working in a dual-stack environment. The DHCPv6 use case should be well scoped. RDNSS is a SHOULD (and Lorenzo would prefer a MUST). Fernando Gont: ask clarification about DNS-SD, Tim: currently nothing said but we should change it Michael Richardson: happy eyeball could also be used when selecting among addresses (such as ULA & GUA). Lorenzo Coliti: the HE RFC clearly specifics dual-stack in the title. Tim Chown: there was also a HE in the defunct MIF WG which is now at the IESG. Candidate encapsulation for BIER, draft-pfister-bier-over-ipv6 , Pierre Pfister, 15 min. ------------------------------------------------------------------------- Presented yesterday at BIER WG where the work is done. A couple of clarification questions from Lorenzo Coliti, Dave Thaler and Erik Kline. Lee Howard and others: how can we get the BIER prefix? Pierre: get it from RIR for example and the I-D does not specify a structure of this BIER prefix. Erik Nordmark: is it enough to have 80 bits only while MPLS encap have many more bits? Tom Herbert: what about the UDP checksum? Xiaohu Xu: with this encap there is a benefit to traverse a non BIER domain Suresh: very constrained domain/use case Lorenzo Coliti: concern about the BIER prefix size and lack of bits, prefer to use an extension header Lee Howard: same concern as Lorenzo + does not like to embed semantics in destination address David Lampater: disagree with Lorenzo, let's use more prefixes if required. Could also use a specific encapsulation (so no extension header or specific address) with a field for the BIER bits Greg Sheperd: feedback of operators is 256 bits would be enough for most of the cases but in some the need would be thousands of bits. Netmod: IPv6 RA submodule options ?, draft-ietf-netmod-routing-cfg , Tim Chown, 10 min. ------------------------------------------------------------------------- We need a YANG doctor from 6man. Consensus is indeed we need to fix the yang submodel and nominate Michael Abrahamsson as the 'volunteer'. Suresh: it is already in IESG queue and we need to go with the current submodel then write an extension I-D. ------------------------------------------------------------------------- Meeting Adjourned -------------------------------------------------------------------------