6MAN Working Group - Singapore IETF Meeting Tuesday, 14 November 2017, 13:30-15:30, Canning Chairs: Bob Hinden, Ole Troan Minute taker: Victor Kuarsingh Jabber Scribe: Mikael Abrahamsson Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf100/6man ----------------------------------------------------------------------- ----------------------------------------------------------------------- Agenda Introduction, Agenda Bashing, Document Status, Chairs, 10 min. NAT64 Experiment, Jen Linkova IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis , Tim Chown, 30 min. IPv6 ND PIO Flags IANA Considerations, draft-troan-6man-ndpioiana , Ole Troan, 10 min. Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers, draft-ietf-opsec-ipv6-eh-filtering , Ron Bonica, 15 min. Recommendation on Temporary IPv6 Interface Identifiers, draft-gont-6man-non-stable-iids , Fernando Gont, 15 min. IPv6 Address Usage Recommendations, draft-gont-6man-address-usage-recommendations, Fernando Gont, 15 min. Route Information Options in Redirect Messages, draft-templin-6man-rio-redirect , Fred Templin, 10 min. IPv6 in-band signaling for the support of transport with QoS, draft-han-6man-in-band-signaling-for-transport-qos , Lin Han, 10 min. ----------------------------------------------------------------------- ----------------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 10 min. -------------------------------------------------------------- - Reviewed agenda Document Status Review (slide) - Reviewed parked document, drafts in IESG - Quick review of active drafts Documents of Interest (slide) - Review documents in opsec, v6ops, and segment routing - Comment from Erik Kline - incoming document from ipwave (incoming potential documents and discussion for 6man) - Ron Bianca volunteered to look at Spring documents - Suresh IPv6 Core standards next steps? (slide) - quick review of slide NAT64 Experiment, Jen Linkova ----------------------------- IPv6 Only Experiment (Presentation) - Jen Linkova - Discussion of desire to use NAT64 SSID, IPv6 based SSID - Report issues to "tickets@" mailing list IPv6 Node Requirements, draft-ietf-6man-rfc6434-bis, Tim Chown, 30 min. ----------------------------------------------------------------------- - Review of slides - Discussion of comments and feedback - includes list of changes - RFC4191 comment (from Erik) - Comment Brian Carpenter on the comment re: MUST vs. SHOULD - Text on IPv6 EH processing (slide) - asking group for comments or texts - Comment Fernando Gont - DHCPv6-PD - Unknown ULP issue - quick review of slide data - discuss proposed text from next slide (10) - Comment Erik Nordmark - Comment Brian Carpenter - - Comment Bernie Volz - what happens if someone asked for EH response? - response text in RFC8200 - Cite RFC1122 - request from Fred Baker - Comment Fred Templin - text related to backwards compatibility would appropriate - Unless they get - Update DHCP vs RA options text - can expanded on it, but have left is as is for now (section 8.4) - can avoid topic (TW's opinion) - Comment Suresh Krishnan - agree to keep it minimal (would not be successful in a short time) - Comment Lorenzo Colitti - regarding stateful vs stateless - should do what the network asks us to do - Comment Suresh Krishnan - the "network" does not tell you want to do - LC - trying to recall text, discuss what the draft says related on the "SHOULD" statement related to what the Network sets - SK - failure of working group to specify - LC - suggests if the host is privacy sensitive, we should drop the SHOULD - ongoing discussion on matter - IPv6 only host (NAT64) - comment (from?) - - comment Alexandre Petrescu - re: IPv6 only hosts if there is IPv4 present (vs. translation) - comment Ole, if you don’t IPv4 have address, its IPv6 only - comment Lee Howard - we have terminology problem, recommended wording - continued comments on nuances of working (re: need for IPv4 stack, etc) - comment Suresh - DNS64 is a man in the middle (DNSSEC is to stop) - question is do we want to synthesize the record - comment Alain Durand - comment about failure rates related to use of NAT64 - - comment Alexandre Petrescu - other comments related to IPv6-only challenges and issues - comment / Bob H - should we put in only requires of IPv6 only host - comment Lorenzo - regarding points 1,2? clarify needs if we are doing DNSSEC validation with NAT64 (suggested wording) - recommends that “if you do DNSSEC”, then note that the first two points on slide are suggested to be done - comment Chongfeng Xie - discussion of LTE devices, and they have different requirements - response from Suresh - notes that the draft relates to general requirements, and one can have more restrictive requirement for certain use cases - comment David Schinazi- this should be about IPv6 notes/hosts. Notes that comm with IP4 literals should not be about that - suggests DNSSEC text should not be in the document / not requirement for iPv6 host - comment Mark Andrews - comments that this should discuss what you need to use IPv4 as a service with iPv6 host - comment Barbara Stark - if there is a MUST, ever device in every use case should need this (suggests that is not sure related to NAT64/DNSSEC - comment Mikael Abrahamsson are all points on this list a “must”? - Document status? - should this be info or BCP? - no comments Active Individual Drafts ------------------------ IPv6 ND PIO Flags IANA Considerations, draft-troan-6man-ndpioiana , Ole Troan, 10 min. ----------------------------------------------------------------------- - Discuss slides, came out of issue for RFC4861 PIO - Problem that 6275 took another bit of reserved field - this creates new registry , updates 6275, but not 4861 - adoption ? - comment: Lorenzo C, comment on approach. - comment Suresh K there is stuff to be done here, we have general issues with updates and flags in the IETF - comment form Old, larger issue on how to manage reserved fields and update them - comment from Suresh - gave example of reserved field with flag. what happens to implementations that already exist - Ole/Suresh - don’t see issue - comment - Erik Kline - support - comment - Mikael Abrahamsson / response from Suresh on policy on experimental, reserving of bits etc - comment Alexandre Petrescu - comment Erik Nordmark - do experiment, then get the / reserve the bits - support for WG doc? - some hums for support, / no response for not support - Chairs will confirm to adopt on the mailing list. Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers, draft-ietf-opsec-ipv6-eh-filtering , Ron Bonica, 15 min. -------------------------------------------------------------------- Presentation not given. Recommendation on Temporary IPv6 Interface Identifiers, draft-gont-6man-non-stable-iids , Fernando Gont, 15 min. -------------------------------------------------------- - discuss intro with draft - tries to address issue with RFC4941 / related to use of Temp addresses - discuss goals of document / start with security requirements for the TA - discuss requirements for non-stable IIDs / there are a number of issues here - comment: Alexandre Petrescu when changing the IID, one needs to be careful (when moving from one network to another) - speaker - you can randomize the MAC address - comment : Lorenzo Colitti is the algorithm currently specific day 4941 allowed or disallowed? / concerned we should not throw out - speaker if we keep 4941, we need to patch - Chair - we can move that to BIS document for 4941 - ongoing discussion about how BIS could be used to update. change items from 4941 - comment Suresh K - WG should maintain it’s specs (which indulges 4941) - SK notes, the WG should decide if we create a BIS or this new draft. either way it can be the same result - no matter what we do (based on SK) ,we should obsolete it (4941) - comment Lorenzo Colitti - we would end up in better place to rev 4941, and fix the bugs - noted examples - comment Lorenzo Colitti - update language on IID / EUI64 addresses - comment Eric Vyncke - comment related to state which is required / confirmed by Erik Kline - comment Erik Kline - 4941 BIS should update the deployment section IPv6 Address Usage Recommendations, draft-gont-6man-address-usage-recommendations , Fernando Gont, 15 min. ---------------------------------------------------------------------- - Discuss draft / intro - Provided summary of document - problems when using multiple addresses with APIs - discuss problems with both incoming and outgoing connections - example, use of TA for outgoing, can then be used for incoming connection (found in wild) - Q - how many people read document ? only 2 people - Chair, ask speaker was there information exchange with Dave Thaler ? suggests this belongs in transport - Comment George Michaelson Suggests we should be able to set conditional flags, (general model), suggests work should not be here - Comment Suresh K - kinda agrees with George (even if Socket API was done in 6man) Chairs take the action to discuss with Transport/Apps regarding where this document belongs. Route Information Options in Redirect Messages, draft-templin-6man-rio-redirect , Fred Templin, 10 min. ------------------------------------------------------- - Motivation is to allow neighbors to share routing information with many nodes , and where tradition routing protocols are impractical. - RIOs were originally included in 4191 which has Type A, B and C hosts - this introduces new type D host (would update 4191) - comment Ole T, whats the purpose of the S flag? can we just do redirect? - speaker response - discussed the ability to have a trust / confirmation - Comment Brian Carpenter - comment on motivation for large networks - apart of WiFi where is the use? - speaker example airplanes world wide (10K nodes) - BC - how is the any better then just routing? - Comment Erik Nordmark - concerned about security implications , re: - traditional models where you trust only your main router/gateway - , anyone can inject any route for anything? - Comment Lorenzo Colitti - have we fixed issue where router can’t depreciate the prefix? - continued discussion on how state is managed, how the router participates with pulling back prefix - LC says we may need applicability statement here (to refine how this will be used) - Comment Erik Nordmark - is there a lease time on this updates? answer Y - Comment Erik Kline - Q on prefix invalidation and confirmation from speaker on process - Comment Chair (Bob) - concerns that WiFi does not support type of communication (direct peer to peer) that is listed in the document - Comment Chair (Bob) - also feels that type D host seems like a router - Comment Lorenzo Colitti - suggests no real benefit - Chairs as people to read and comment on list IPv6 in-band signaling for the support of transport with QoS, draft-han-6man-in-band-signaling-for-transport-qos , Lin Han, 10 min. --------------------------------------------------------------------- - speaking provides quick overview draft, will also be presented in - transport area meeting. - motivation reviewed with audience - speaker reviews slides on transport control sub-layer - speaker reviews slide for IP in-band signaling and QoS for transport - review solutions slide - review in- band signaling slide / with diagram - Comment Erik Vyncke, recommended some text removes and comment on EH. ------------------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------------------