6MAN Working Group - Honolulu IETF Meeting Friday, 0900-1130, 14 November 2014, Coral 3 Chairs: Bob Hinden, Ole Troan Minute taker: Pascal Thubert Jabber Scribe: Andrew Yourtchenko Jabber Room: 6man@jabber.ietf.org Meetecho: http://www.meetecho.com/ietf91/6man Slides can be found at: http://www.ietf.org/proceedings/91/6man.html ----------------------------------------------------------------------- Agenda ----------------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Working Group Drafts Efficient ND Design Team, Status Repot, Erik Nordmark, 20 min. Recommendation on Stable IPv6 Interface Identifiers, draft-ietf-6man-default-iids-01.txt , Fernando Gont, 10 min. Active Individual Drafts Deprecating the Generation of IPv6 Atomic Fragments, draft-gont-6man-deprecate-atomfrag-generation-01 , Fernando Gont, 15 min. Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO), draft-skeen-6man-ipv6geo-01.txt , Brian Skeen, 15 min. The IPv6 Flow Label within a LLN domain draft-thubert-6man-flow-label-for-rpl-05.txt , Pascal Thubert, 15 min. IPv6 Prefix Length Recommendation for Forwarding, draft-boucadair-6man-prefix-routing-reco-03.txt , Alex Petrescu, 10 min. Validation of IPv6 Neighbor Discovery Options, draft-gont-6man-nd-opt-validation-01.txt , Ron Bonica, 10 min. Overview of Source Address Dependent Routing, draft-sarikaya-6man-sadr-overview-02.txt, draft-sarikaya-6man-next-hop-ra-02.txt, draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00.txt, Bechet Sarikaya, 10 min. IPv6 Segment Routing Header (SRH), draft-previdi-6man-segment-routing-header-03.txt, draft-vyncke-6man-segment-routing-security-00.txt , Eric Vyncke, 10 min. New Individual Drafts CGA SEC Option for Secure Neighbor Discovery Protocol, draft-jiang-6man-cga-sec-option-00.txt , Dacheng Zhang, 5 min. CGA Security Improvement, draft-rafiee-rfc3972-bis-00 , Hosnieh Rafiee, 5 min. IPv6 Flow Label Reflection, draft-wang-6man-flow-label-reflection , Sheng Jiang, 5 min. IPv6 ND Option for Network Management Server Discovery, draft-liu-6man-nd-nms-discovery-00.txt , Bing Liu, 5 min. Transmission and Processing of IPv6 Options, draft-gont-6man-ipv6-opt-transmit-00.txt , Fernando Gont, 5 min. Introduction, Agenda Bashing, Document Status, Chairs, 15 min. ------------------------------------------------------------------------------------------ Chairs provide document status 3 adoption calls, plus one in queue (see slides) Asking for comments, none from the room. Working Group Drafts ------------------------------------ Efficient ND Design Team, Status Report, Erik Nordmark, 20 min. ---------------------------------------------------------------------------------------------- History of DT since London IETF 89 About sub-optimality in IPv6 ND, discussed potential problem areas and operational techniques to make things better. Measurement results in 2 drafts (see slides). reported to 6ops. Erik lists areas of concerns: - ND multicast in general - DAD There are places where existing ND works well, so we should not be disrupting that. There is a range of behaviors for (duty cycled) sleeping devices, e.g. wake on packet vs. periodic schedule. In some cases, ND is a very small piece of the problem (e.g. vs. multicast DNS). RS does not seem to be an issue. Easily filtered since sent to all routers, not sent on Wi-Fi usually. multicast RA is more of a problem. Also, a draft about cellular indicates that unsolicited RAs may cause explosion of paging in the network (1M host) to find the target before the RA is delivered. NS/NA can be alleviated with L=0 (not on-link), sleep proxies may cause unsolicited NA in case of MAC address transfer. New draft on DAD issues to consider if we are to do something different. DAD is unreliable? how reliable should it be ? What about link split / rejoin ? Already docs on operational technique to reduce though implicit or explicit filtering. e.g. splitting the L2 domain if the expectation is to reach the outside as opposed to operate on link local. ComCast appears to deploy handing out a /64 per user in stadiums (no actual doc here). RS/RA improvements: change the max allowed limit. Apparently it is deployed already. Solicited RAs should e answered unicast. Allow to flip the model so that the host indicates that it will poll the router as opposed to wait for unsolicited and randomize the reqs. Support by hosts and routers can be signaled so the operator sets up policies. Duty cycled host may see different behavior when waking up before next RS polling time, if it missed RAs that deprecated stuff and may wait to the next polling time to learn again. DAD side: what about the list of 11+ problems? DT talked about solutions, snooping or registration DAD choices, see slides. Pascal Thubert indicates that explicit registration is useful vs. implicit because hard to discover misses. Michael Abrahamsson: need to improve multicast either here or at IEEE. Should the IETF collect information to help IEEE address it? Erik: It is not only multicast, e.g. sometimes the spanning tree is not up yet and the host cannot tell. Also network split and merge. Dave Thaler: supports RS refresh. Same problem in NBMA as in Wi-Fi. A generic version of the NBLA work could be useful. in Windows, the implementation is over-foo agnostic. Fred Templin: liveliness is important xxx: 2 issues. RA interval mobile IP depends on short interval. need to clarify why DAD, role of DAD. Lorenzo C.: will force to change implementations which do not forward unless they see a DAD, and that will be a good thing. Erik: Q1 is whether we do something or nothing Lorenzo C.: a number of the 14 issues are already solved Recommendation on Stable IPv6 Interface Identifiers, draft-ietf-6man-default-iids-01.txt , Fernando Gont, 10 min. ----------------------------------------------------------- Intro to the doc, about IPv6 over foo recommends using 7217. Reviews from Ralph Droms and Carsten Bormann. See slides for issues. Alexandru Petrescu agrees with Dave Thaler because the IID can help debug a network Kerry Linn: a single MUST in Dave's text seems to force all nodes. Dave Thaler: first MUST is for any foo . Dave accepts that the last SHOULD can be an update by reflashing the device, and it is a SHOULD anyway. Alyssa Cooper: response to Kerry: Dave's sentence could be clearer in the subject. Goal would be to narrowly define when the recommendation applies. Juan Carlos Zuniga: text too ambiguous. Exceptions should be explicit. If privacy is our recommendation then then the SHOULD would be about when it is disabled, there SHOULD be a good reason why. Lorenzo: L2 privacy should apply to all addresses. Fernando: example of mail servers on link (e.g. found by bonjour) can leak a link local address. Discussion already happened in London for this doc Erik Nordmark: doc is silent about applicability to link local, that should be explicit. Is it worth pointing out that we would link underlying technology to provide privacy. Randy Turner: Does define mean implement? Dave Thaler: only 3rd sentence is about implementation. Samita: agree we need to change for IPv6 over foo. But why is the first sentence a MUST instead of a SHOULD. Else there is a need for clarification. Do we need the MAY sentence. Jen Linkova: seems that the cost is put on properly configured networks. Desire to connect to devices that are known by mac address. Desire to have a permanent stable address. X: Not so much privacy but not leaking Pascal: Need to loosely couple the L2 and L3 privacy addresses, properties may be different. E.g. lifetime, or trigger to renew. Bob suggests to move on and follow up on mailing list. Active Individual Drafts ------------------------------- Deprecating the Generation of IPv6 Atomic Fragments, draft-gont-6man-deprecate-atomfrag-generation-01 , Fernando Gont, 15 min. --------------------------------------------------------------------- Stateless IP/ICMP Translation Algorithm (SIIT) IPv4 frag ID is only 16 bits and at decent rate is not reliable. Fernando describes attacks. Suresh K: Slippery slope. Point solution for one issue of atomic frags. What about forge PTB for other size like 1281 bytes packets. I accept problem is real. we should either deprecate frags or not do anything. Andrew Yourtchenko: Fix should be in TCP. Fred Templin: in MANET we need atomic fragments. Can't broadly deprecate them. Erik N.: supports simplification in the spec. We could day it's OK for firewall to filter atomic frags that should not cross certain boundaries. Ron Bonica: Valid problem. Amplify Suresh's point. Need to consider deprecating frags. Eric Kline: Should be able to write a stack that only sends up to 1280. Suresh K.: summary of stack behavior very useful Jen Linkova: seems that we are fixing what's easy to fix as opposed to the real problem? Ole: difference between removing the words in 2460 and banning atomic fragments completely No consensus to move forward at this time. Work will continue on the mailing list. Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO), draft-skeen-6man-ipv6geo-01.txt , Brian Skeen, 15 min. --------------------------------------------------------------------- Meetecho blocked by corporate firewall so Fred does talk on behalf. reading slides. Fred describes aircrafts use case. Links vary and not all have Link layer geo info. Ipv6 the only common layer. Martin Thomson: this is a geopriv issue. Challenging that IPv6 is the only thing in common. All the upper layers are in common. If you need to tell someone where you are is go and tell them. Lorenzo C.: tech comment what about lying about location. What this tells is we need vendor option space since on the overall internet it would be a privacy issue and insane to support. Better strategy should be to ask for vendor space to do stuff in the privacy of my own network Fred Templin: I want interop Lorenzo: yes, writing an informational xxx: supporting vendor option. Lots exist at app layer which solve all issues including privacy.Draft should focus on hard case when the L3 approach is the only possible. Fred: yes, this is for private network use but need interoperable implementation. Alex Petrescu: Geo has more precise nature. Privacy: is the destination option protected by ESP Fred T.: can be and if so privacy is addressed Martin Thomson: need to indicate that it has to be between consenting peers. Geopriv facilitates that sort of things, thats the key. A lot of redundancy with geopriv. James Woodyatt: happy of genuine use case for geopriv data. real value for informational. Unsure about WG doc. Probably overkill for a whole dest option code. Maybe not vendor but maybe more general purpose than this Fred T.: concerned about safety. Want to speak the same information Igor Gashinsky: Iphone beaconing my location is terrifying. The kernel is the right place to decide privacy. Support vendor org or private thing that could be filtered. too close to shoot yourself in the foot. must be more difficult for people to use Andrew Y.: please mandate encryption. Richard Barnes: filtered at the routers. Ole T.: we try to put IPv6 end to end Bob: Continue the discussion on the mailing list. The IPv6 Flow Label within a LLN domain draft-thubert-6man-flow-label-for-rpl-05.txt , Pascal Thubert, 15 min. ---------------------------------------------------------------- (Pascal: since I'm the note taker not many notes there) Brian Carpenter expressed support, Lorenzo indicates that the zero flow label could be obtained by configuration since it is a single admin domain Brian Haberman expressed concern on how much we open this but then as long as it is contained in a domain. IPv6 Prefix Length Recommendation for Forwarding, draft-boucadair-6man-prefix-routing-reco-03.txt , Alex Petrescu, 10 min. ----------------------------------------------------------------- Igor Gashinsky: MUST NOT seems pretty strong Lorenzo C. : some vendors do not support some sizes. Should recommend practices. Shy away from changing size of IID. Ole T. : unclear what 6MAN spec should be updated Lorenzo C.: v6ops can clarify, 6MAN has been working like that forever since forwarding is not related to IID length. Fernando G. This is a clarification so it belongs to 6MAN Lee Howard: We would not kick it off. Result of the discussion was to see if V6OPS would take this document on as it does not change any IPv6 specification, but make an implementation recommendation. Validation of IPv6 Neighbor Discovery Options, draft-gont-6man-nd-opt-validation-01.txt , Ron Bonica, 10 min. -------------------------------------------------------------------------- Chairs asked for a show of hands of whom had read it. Not many people in the room had read the draft. The chairs will do an adoption call on the list. Overview of Source Address Dependent Routing, draft-sarikaya-6man-sadr-overview-02.txt, draft-sarikaya-6man-next-hop-ra-02.txt, draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00.txt, Bechet Sarikaya, 10 min. ----------------------------------------------------------------------- (No notes) IPv6 Segment Routing Header (SRH), draft-previdi-6man-segment-routing-header-03.txt, draft-vyncke-6man-segment-routing-security-00.txt , Eric Vyncke, 10 min. ----------------------------------------------------------------------------- (No notes) ----------------------------------------------------------------------- Meeting adjourned ----------------------------------------------------------------------- There was no time to present any drafts in the “New Individual Drafts” section. New Individual Drafts ------------------------------ CGA SEC Option for Secure Neighbor Discovery Protocol, draft-jiang-6man-cga-sec-option-00.txt , Dacheng Zhang, 5 min. CGA Security Improvement, draft-rafiee-rfc3972-bis-00 , Hosnieh Rafiee, 5 min. IPv6 Flow Label Reflection, draft-wang-6man-flow-label-reflection , Sheng Jiang, 5 min. IPv6 ND Option for Network Management Server Discovery, draft-liu-6man-nd-nms-discovery-00.txt , Bing Liu, 5 min. Transmission and Processing of IPv6 Options, draft-gont-6man-ipv6-opt-transmit-00.txt , Fernando Gont, 5 min.