6MAN Working Group - Yokohama IETF Meeting Wednesday, 0900-11300, 4 November 2015, Room 501 Chairs: Bob Hinden, Ole Troan Minute taker: Erik Kline Jabber Scribe: Suresh Krishnan Jabber Room: 6man@jabber.ietf.org Meetecho: http://www.meetecho.com/ietf94/6man Slides can be found at: https://www.ietf.org/proceedings/94/6man.html The full recording (synchronized video, audio, slides and jabber room) of the 6MAN WG session at IETF 94 is available at https://ietf94.conf.meetecho.com/index.php/Recorded_Sessions#6MAN ----------------------------------------------------------------- Agenda ----------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Review: Other WG's use of IPv6 extension headers, Chairs, 10 min. Working Group Drafts: Host routing in a multi-prefix network, draft-ietf-6man-multi-homed-host, Fred Baker, 15 min. IPv6 specifications to Internet Standard, draft-ietf-6man-rfc2460bis, draft-hinden-6man-rfc4291bis , Bob Hinden, 45 min. Active Individual Drafts ------------------------ IPv6 Hop-by-Hop Header Handling, draft-baker-6man-hbh-header-handling, Fred Baker, 15 min. Transmission and Processing of IPv6 Options, draft-gont-6man-ipv6-opt-transmit, Fernando Gont, 10 min. IPv6 Universal Extension Header, draft-gont-6man-rfc6564bis, Fernando Gont, 10 min. Support for adjustable maximum router lifetimes per-link, draft-krishnan-6man-maxra, Suresh Krishnan, 10 min. IPv6 Segment Routing Header (SRH) draft-previdi-6man-segment-routing-header, Roberta Maglione, 10 min. Multiple Provisioning Domains using Domain Name System, draft-stenberg-mif-mpvd-dns, Markus Stenberg, 10 min. New Individual Drafts --------------------- Uplink access technology indications in Router Advertisements, draft-krishnan-6man-uat, Suresh Krishnan, 05 min. DNS Name Autoconfiguration for Internet of Things Devices, draft-jeong-6man-iot-dns-autoconf-00, Jaehoon (Paul) Jeong, 5 min. ----------------------------------------------------------------- ----------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 10 min. ----------------------------------------------------------------- Chairs reviewed the agenda, note well, and summary of document status. Review: Other WG's use of IPv6 extension headers, Chairs, 10 min. ----------------------------------------------------------------- draft-ietf-conex-destopt 6man chair feedback sent and accepted draft-ietf-ippm-6man-pdm-option new destination header option Host routing in a multi-prefix network, draft-ietf-6man-multi-homed-host, Fred Baker, 15 min. ----------------------------------------------------------------- - src/dst routing - aimed at avoiding BCP38 ingress filtering - host behaviour [ this model ] - 1:1 relationship between a prefix and a first hop router - same as used in SAVI - a multi-connected host cannot presume the first router can correctly redirect packets sent out the wrong interface (e.g. Wi-Fi and LTE on a mobile device) - updated interpretation of RAs - default router selection - source address selection could be unchanged - general comments [ Pierre Pfister ] - could work in a homenet context - can hosts handle redirects correctly? [ Arifumi Mastumoto ] - support the draft - background shares motivation with multihoming without NAT draft [ Lorenzo Colitti ] - let's not rely on redirects (slow, get lost) - they should be a last resort - don't want to have to remember history of what works and what doesn't [ Dave Thaler ] - document what we want hosts to do? - [fred] not describing what they do do, but what they should do [ Pierre Pfister ] - please don't remove redirects, affects homenet [ Erik Kline ] - rfc6724 section 4, MUST vs SHOULD IPv6 specifications to Internet Standard, draft-ietf-6man-rfc2460bis, draft-hinden-6man-rfc4291bis, Bob Hinden, 45 min. ----------------------------------------------------------------- - move IPv6 RFCs to Internet Standard (RFC2026) - discuss include updating RFCs - request to reclassify docs that don't need changes - 2460bis and 4291bis - request volunteer to examine 4443 vis. 4884 - Ron Bonica has volunteered [ Christian Huitema ] - process point of view: errata should be given due consideration [ Erik Nordmark ] - other pMTUd draft (packetization layer) - update should have a reference to it - 2460bis - ~10 RFCs incorporated, plus 3 errata - fun with fragmentation - 5722: don't create and drop overlapping fragments - 6946: rule for processing atomic fragments - 7112: require all headers through upper-layer inclusive are in the first fragment - draft-ietf-6man-deprecate-atomicfrag-generation: remove ICMP Packet To Big if MTU < 1280 - 5095 and 5871: RH0 deprecation and IANA references - fun with Flow Labels and Traffic Class - flow label now points to 6437 - traffic class points to DSCP and ECN documents - 6564: extension headers format - new HBH not recommended - use DST options instead [ Dave Thaler ] - clarify recommendations about new HBH versus new extension to HBH - 6935 update: zero UDP checksums for tunneled packets [ Dave Thaler ] - "must" -> "MUST"? - see later slide - 7045 about HBH updates [ Dave Thaler ] - bold should -> "SHOULD"? - see later slide - inserting extension headers classified verboten - data transmission order: see 791 - deprecate atomic fragments - remove paragraph reacting to PTBs with MTU < 1280 [ Dave Thaler ] - you are not required to lower MTU less than 1280 - [Bob Hinden] that text is stated elsewhere - clarification of fragment text - 1st fragment MUST incude up through upper layer header places an upper bound - lots of headers can exceed fragmentable maximum - RFC2119 bikeshed - RFC2119 not required, nor is uppercase - [Ole Troan] we won't spend the rest of the meeting on this [ Philip Matthews ] - if you don't put uppercase people read lowercase - add a comment that they're the same? [ Wes George ] - bring it up to current standards [ Lorenzo Colitti ] - recent documents use RFC2119 uppercase because it is useful - reduces ambiguity - this document will stand for quite some time - [Bob Hinden] some degree of interoperability already achieved - we have to have arguments with vendors and use UPPERCASE to resolve disagreements - need beyond reasonable doubt style of clarity [ James Woodyatt ] - agree with doing RFC2119 - if we don't we're going to continue to have arguments with people who benefit from ambiguity [ Lee Howard ] - capitalization required is stupid [ Erik Nordmark ] - recollection of Steve Deering, everything's fine [ Christian Huitema ] - (comment missed) [ Philip Matthews ] - uppercase helps, had discussions and arguments and uppercase is clearer [ John Scudder ] - If every lowercase is uppercase, resolve this problem with sed - if sed doesn't solve it then there're other issues - handling of duplicate fragments - currently treated as overlapping and discarded - propose text that dups can happen, and implementations can handle or not, either is fine (fixed by retransmission) [ Dave Thaler ] - potential issue with multicast (tree MTU discovery) - agree we can just describe the issue - obsolete some docs, wg last call? [ Brian Haberman ] - implementation reports aren't required anymore - some means to demonstrate interoperability is needed [ Timothy Winters ] - UNH IOL can put together whatever is needed [ John Jason Brzozowski ] - operator community can provide input [ Dave Thaler ] - if we obsolete a document that we need...? [ Fernando Gont ] - overlapping fragments is well-implemented [ Wes George ] - "IPv6 is a new internet protocol, ..." - should obsolete IPv4 at this same time? [ Dave Thaler ] - we would need to incorporate data transmission ordering text from 791 - rfc4921bis - 5952 update: address string representation - 7346: scope description, including 4007 realm-local scope - 6052: point to IANA registries - 7136: U and G bit deprecation and modified EUI-64 - 7371: flag bits for multicast - 4291bis hum: in favor of adoption, confirm on mailing list - volunteer for 1981 review? - Christian Huitema IPv6 Hop-by-Hop Header Handling, draft-baker-6man-hbh-header-handling, Fred Baker, 15 min. ----------------------------------------------------------------- - if HBH is not first extension header, MUST drop - options permitted to be changed in transit supported by 2460 - what if network is doing something the host didn't know about? - adding headers or options in transit for OAM (Operations, Administration, and Maintenance) purposes - adverse interaction with AH security extension header - IPv6 header must be restored to original before final delivery - does not apply to EH (but that does cover DST options header) - two host talking across a network, one or more routers add info, info (most likely) removed before delivery to host [ Bob Hinden ] - don't support adding stuff in the middle - encapsulate instead [ Roberta Maglione ] - spring using encapsulation now [ Lorenzo Colitti ] - don't see the harm in doing this - should say why no extension headers shouldn't be inserted - what's the harm? [ Erik Nordmark ] - you're changing the length but not source so pMTUd is impacted - for encapsulation the error goes back to the encapsulating node - you may need to rewrite ICMP PTBs at a network boundary, which is hard to do right - modifying headers of constants size doesn't have MTU issues [ Christian Huitema ] - useful for correlation - but changing the length of packet and measuring performed of modified packets is inherently problematic - can we mark packets with minimal impact on the transmission chain? [ Ole Troan ] - thanks for enumerating the issue - went back to 791, you're changing the packet length in flight definitely affects pMTUd - concerned about adding this to 2460bis - cooperating administrative domains? things leak [ Jen Linkova ] - should clarify why we are not permitting this - because there are potential use cases [ Lorenzo Colitti ] - the reason we can't do this is that we can't count? - if you have a network you can guarantee MTU - if this is a problem we can't solve seems specious [ Nalini Elkins ] - we're using a destination option in IPPM - DST can be before and after, we suggest before (re: integrity checks) [ Mark Townsley ] - agree with Lorenzo - either we do it in IPv6 or we do this in layer 2 or something proprietary - don't see the big problem Transmission and Processing of IPv6 Options, draft-gont-6man-ipv6-opt-transmit, Fernando Gont, 10 min. ----------------------------------------------------------------- - because: middle-boxes - 7045 for ipv6 options - SHOULD forward packets regardless of Destination Options - if they inspect they MUST recognize ...lots - request IANA to update parameters registry [ Dave Thaler ] - no objection [ Ole Troan ] - not a problem for end hosts? [ Fernando Gont ] - yes and no, end hosts have to validate too [ Erik Nordmark ] - MUST default to forward the packet? - firewall might have a default policy to drop unknown things - might not be disable-able - current text seems to be unenforceable [ Fernando Gont ] - but this is just "7045 for options" [ Mikael Abrahamson ] - the vendor needs to take the registry and compile it into a form for validating options? [ Erik Nordmark ] - 7045 has standard extension headers - issue of future versus past [ Ron Bonica ] - possible compromise: it's ok to drop it so long as you have a config option to do otherwise [ Bob Hinden ] - can't be generalized in code IPv6 Universal Extension Header, draft-gont-6man-rfc6564bis, Fernando Gont, 10 min. ----------------------------------------------------------------- - EH or upper-layer can't be easily determined, same numberspace - 6564 defines a uniform format - still can't tell if uniform format is used - propose one new EH format to rule them all, and to try to to banish further extension numbers to another numberspace [ Dave Thaler ] - no objection - sometimes the ambiguity is a feature - potentially a solution to update the "mutable part" of a packet [ James Woodyatt ] - was a known issue at 6564 time - add a new reserved EH and close the registry, requiring standards action to reopen - I'm okay with reserving zero numbers [ Philip Matthews ] - a router may need to read stuff for ECMP [ Stephen Barth ] - an new EH is mandatory to understand and unskippable [ Bob Hinden ] - another carrier for options - still can't know if internal subtypes can be skipped or not - semantically the same, doesn't add anything over DestOpt [ Erik Nordmark ] - middle-boxes don't make life fun - but I don't think solves any of the protocol design problems introduced by middle-boxes [ James Woodyatt ] - the reason we have 6564 is because application listener discovery involved a new header to be processed by middle-boxes - could have used a HBH, but then every middle-box has to examine it Support for adjustable maximum router lifetimes per-link, draft-krishnan-6man-maxra, Suresh Krishnan, 10 min. ----------------------------------------------------------------- - ND timers have issues on some links - K = (AdvDefaultLifeTime/MaxRtrAdvInterval) to determine RA drop rate - K >= 2 on normal networks - update MaxRtrAdvInternal to 65k - update AdvDefaultLifetime to <= 65k - relax RA sending behaviour [ Lorenzo Colitti ] - max lifetime 64k, v6ops has some power numbers - send RAs every 10-15 minutes very low power - some devices drop up to 65% of multicast (or more) - separate change max from disabling periodic RAs [ Jen Linkova ] - clarify update to 4861? can still use 0? [ Stephen Barth ] - made this change in OpenWRT - this works in practice - adoption hum: generally for, none against IPv6 Segment Routing Header (SRH) draft-previdi-6man-segment-routing-header, Roberta Maglione, 10 min. ----------------------------------------------------------------- - header insertion was seem as problematic - using outer encapsulation - security - using HMAC - remove references to SDN - MTU and ICMP error handling - using outer encapsulation - reference to terminology doc [ Ron Bonica ] - need to retain C flag in the SRH [ Mark Townsley ] - support this as a working group document - what we decide w.r.t. insertion of extension headers, this doc should be updated after the dust has settled [ Erik Nordmark ] - no problem with people doing the work to evaluate impact ----------------------------------------------------------------- ----------------------------------------------------------------- At this point the meeting was adjourned as we had run out of time. The material for the following presentations is included in the proceedings. Multiple Provisioning Domains using Domain Name System, draft-stenberg-mif-mpvd-dns, Markus Stenberg, 10 min. Uplink access technology indications in Router Advertisements, draft-krishnan-6man-uat, Suresh Krishnan, 05 min. DNS Name Autoconfiguration for Internet of Things Devices, draft-jeong-6man-iot-dns-autoconf-00, Jaehoon (Paul) Jeong, 5 min. ----------------------------------------------------------------- -----------------------------------------------------------------