6MAN Working Group - Dallas IETF Meeting Monday, 0900-1130, 23 March 2015, International room Chairs: Bob Hinden, Ole Troan Minute taker: Erik Kline Jabber Scribe: Michael Richardson Jabber Room: 6man@jabber.ietf.org Meetecho: http://www.meetecho.com/ietf92/6man Slides can be found at: http://www.ietf.org/proceedings/92/6man.html ----------------------------------------------------------------------- Agenda ----------------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 15 min Working Group Drafts Validation of IPv6 Neighbor Discovery Options, draft-ietf-6man-nd-opt-validation , Ron Bonica, 15 min. Active Individual Drafts A survey of issues related to IPv6 Duplicate Address Detection, Andrew Yourtchenko, Erik Nordmark, 15 min., draft-yourtchenko-6man-dad-issues, draft-nordmark-6man-dad-approaches IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh, draft-nordmark-6man-rs-refresh , Erik Nordmark, 15 min. Source Address Dependent Routing and Source Address Selection for IPv6 Hosts, draft-sarikaya-6man-sadr-overview-05 , Behcet Sarikaya, 15 min. Source Address Dependent Route Information Option for Router Advertisements, draft-pfister-6man-sadr-ra , Pierre Pfister, 15 min. IPv6 Segment Routing Header (SRH), draft-previdi-6man-segment-routing-header, Stefano Previdi, 10 min. IPv6 Segment Routing Security Considerations, draft-vyncke-6man-segment-routing-security , Eric Vyncke, 10 min. Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol, draft-ietf-mif-mpvd-ndp-support , Suresh Krishnan, 10 min. New Individual Drafts Current issues with DNS Configuration Options for SLAAC, draft-gont-6man-slaac-dns-config-issues , Fernando Gont, 5 min. Transmission and Processing of IPv6 Options, draft-gont-6man-ipv6-opt-transmit , Fernando Gont, 5 min. Improving Scalability of Switching Systems in Large Data Centers, draft-zhang-6man-scale-large-datacenter , Ming Zhang, 5 min. IPv6 Flow Label Reflection, draft-wang-6man-flow-label-reflection, Aijun Wang, 5 min. --------------------------------------------------------------------------- --------------------------------------------------------------------------- Introduction, Agenda Bashing, Document Status, Chairs, 15 min ------------------------------------------------------------- - introductory comments from chairs - note wells well noted - Michael Richardson volunteered as Jabber scribe - agenda bashing - Francis Dupont: - request to push IPv6 RFCs to full standards - hinden concurs, in charter, will talk to area director - review of document status - one request for adoption, on today's agenda (sadr-overview) Working Group Drafts -------------------- Validation of IPv6 Neighbor Discovery Options, draft-ietf-6man-nd-opt-validation , Ron Bonica, 15 min. ------------------------------------------------------- - Ron Bonica presenting - adopted as wg item since last IETF - tightening up the document - on suggestion from Jimmei Tatuya: - if you get a message with a link-layer address option that is your own address, should drop (subject to configuration to the contrary) - Jen Linkova, Google - re: one's own address, this sounds like DAD packets - might break DAD for link-local address? - honor the message but not create an ND entry - RFC 4861 validation is per message, this document is per option - slightly confusing? - Fernando Gont - consider a host with multiple NICs on a the same link - need to consider this corner case - Bonica: perhaps configuration option could address this case Active Individual Drafts -------------------- A survey of issues related to IPv6 Duplicate Address Detection, Andrew Yourtchenko, Erik Nordmark, 15 min., draft-yourtchenko-6man-dad-issues, draft-nordmark-6man-dad-approaches ----------------------------------------------------------------------- - Erik Nordmark presenting, channeling Andrew Yourtchenko - draft has been reorganized - open issues (robustness and efficiency) - interaction with delays in forwarding - modem acts as a bridge, but upstream link isn't up so ND messages aren't actually being forwarded - DAD probes lost - resilient-rs solves the problem for RS/RA - unreliable L2 multicast - WiFi, for example, multicast is less reliable than unicast - IEEE 802.11aa working on improved multicast reliability (but more focused on multicast video stream reliability) - partitioned and re-joined links - only DAD at config time - IPv4 has ACD (RFC 5227) which does continuous DAD detection - RFC 4862 doesn't specify retry/recover on collision behaviour - RFC 4941 (privacy) says generate new IID and try again - DHCPv6 should DAD and decline if duplicate - as long as link-local isn't duplicate don't need to disable the interface - energy efficiency - WiFi multicast consumes more bandwidth (energy?) than unicast - host efficiency: better support for sleeping nodes - wake-up and L2 events - RFC 4862 says do DAD when assigning address to interface, nothing about link up/down events - DNA (6059) says SHOULD NOT DAD on re-attach to previously visited link - seems unfortunate - Suresh Krishnan: - our understanding of duplicate situation was different in the past - worth revisiting - with VMs we might need to revisit duplicate probability calculations - Christian Heuitema, Microsoft: - scalability of multicast is an issue - lots of multicast groups (solicited node) - problem with DAD is you're looking for extremely rare events - means the code that deals with this doesn't get exercised very often - you can do testing by collisions, but those are artificial lab conditions - Brian Carpenter: - observation: DAD is ND for yourself - so the problems should apply to ND as well - (Nordmark: but ND retransmits, and waits for positive ACK, but how long does DAD wait?) - Murphy's law proves collisions will happen - Christian Heuitema: - we have to design that these things are difficult - a test at time T is assumed to be valid for some period of time thereafter - a continuous mechanism might be better - Lorenzo Colitti: - shouldn't work on efficiency because we consider this to be rare (sleepy nodes) - discussion of hosts that sleep on a schedule... - LC: if you can't receive a packet you don't have an address - EN: DHCPv6, sleep proxies - LC: yes, can't solve this without an anchor, but this isn't a priority - for multicast efficiency, this is just ND, and if links can't support ND then everything falls over - for robustness: it's designed as best effort to tell you something is wrong - why does this need to be made reliable? - (Pascal): - re: IEEE claims, it's not clear what ND expectations are - reliance on MLD is mandated but kind of broken - John Brzozowski: - think we do to solve this, there are links with large numbers of nodes - have needed lots of work-arounds - EN: to what extent do we care about sleeping hosts - EN: 6man-dad-approaches - continuous DAD, inspired by ACD - allow sleep with robust DAD using sleep proxy IPv6 Neighbor Discovery Optional Unicast RS/RA Refresh, draft-nordmark-6man-rs-refresh , Erik Nordmark, 15 min. ------------------------------------------------------- - Erik Nordmark presenting - periodic RAs can be inefficient on some links, fine for others - maxRtrAdvInterval tinkering maybe not sufficient - operator can choose between unicast RS refresh or periodic multicast RAs - require that RS refresh hosts MUST implement resilient-rs - proposed RS flag: R-flag - this host can do unicast rs refresh - proposed RA option saying if you can do rs-refresh here's the periodicity - routers should respond to unicast RS's with unicast RA's - RS with unspecified source address? - when router has a change, can multicast RA - removing info is harder in RFC 4861 - sleeping/unattached node might not see prefix deprecation message - DNA doesn't even require revalidation - Suresh Krishnan: - for efficiency, NS and RS probes can happen at the same time - Sleeping hosts - DNA says unicast NS to old default router(s) - better to couple with RS refresh - can get new prefixes and other information - RFC 4861 nodes without resilient-rs? - lost RS has to wait for 1800 seconds for periodic RA - could increase to 65535 seconds (6man-maxra) - operational considerations - can I disable periodic multicast RAs? - if the network melts from this then there are other problems :) - likely not worthwhile unless controlled environment - open issues - refresh time, 16bits -> 32bits? - update DNS to use RS/RA when RTO? - require sleeping hosts which ignore multicast RA to use RS refresh? - other optimizations when nothing changes - include epoch number in RA - Lorenzo Colitti: - beware of "how before should" - the average environment doesn't need any of this - mobile devices actually transmit all the time (mail synching, ...) - reconciling all goals may be too difficult - why do anything? - EN: RS+RA serves as a protocol with an acknowledgement - hosts should refresh there information - multicast refresh - responses should be unicast - Fred Templin: - update IPv6 over foo documents? - different link layers have different attributes - EN: this is a configuration knob, for environments that benefit, default is still RFC 4861 behaviour. - Suresh Krishnan: - re LC: agreed,not a problem for mobile phones, but is a problem for sensor networks - sleeping mobile nodes do have issues - Fernando Gont: - agrees to adoption - volunteers to review Source Address Dependent Routing and Source Address Selection for IPv6 Hosts, draft-sarikaya-6man-sadr-overview-05 , Behcet Sarikaya, 15 min. ---------------------------------------------------------------------- - Behcet Sarikaya presenting - sadr-overview draft, requesting adoption - next hop issue - VPN is an issue - next hop RA with a VPN router - (inscrutable network diagram, possibly a Picasso home network) - seeking consensus on solutions - should we define next hop option for RA? DHCPv6? - Alex Petrescu: - VPN question: using VPN with IPv6? (Behcet: yes) Enterprise grade? (Behcet: yes) - Brian Haberman (with AD hat): - we have a liaison statement, "looking into this" - they are not looking for us to define solutions - Behcet: I don't know what's going on in BBF - Steven Barth: - mentioned PIO and 4191, but 4191 describes RIOs, what's up with that? - Behcet: what is the point? This is draft-pfister, so... - (confusion) - Lorenzo Colitti: - How does the VPN router know what's going on inside the other networks? - Behcet: we assume that they know the next router in the home - what if my default router changes or I add a new one? - Behcet: maybe you're no longer on VPN, ... - Ole Troan: - you're proposed 3rd party provides next hop information - Alex Petrescu: - if this is for VPN, then VPN also has a mechanism to provide this info - RAs over a tunnel will send a source address of the VPN gateway not from the BNG or cellular gateway Source Address Dependent Route Information Option for Router Advertisements, draft-pfister-6man-sadr-ra , Pierre Pfister, 15 min. -------------------------------------------------------------------- - Pierre Pfister presenting - quick problem statement summary - consequences: - bcp38 dropped packets || inefficient routing || redirect ping-pong - new RA option, 4191 RIO + source prefix, SADRIO - in classic RIO, add Ignore bit: if you're SADRIO aware you ignore the RIO for a SADRIO prefix - host requirements: - include source prefix in (dest, router, interface) tuple - when sending do dest longest match, then source longest match, then router preference value - router requirements - do not send multiple SADRIOs with same src and dest prefixes - do not send multiple RIOs with same dest prefix - address some FAQs (why not just PIOs, why ignore bit, tlv alignment) - 60 more lines of code in Linux kernel (first attempt) - Suresh Krishnan: - I would like alignment - move all octets one to the left - Behcet Sarikaya: - when I said PIO I should have said RIO - why change the name to destination prefix? - Dave Thaler: - with 4191 author hat: I think you're doing the right thing, good work - recommend you define type D host: type C plus SADR - one multi-homed router giving to different prefixes is the harder design case, which this addresses satisfactorily - rule 1 says avoid unreach destinations, if an app specifies the source address then rule 1 can make use of this information - Lorenzo Colitti: - agree with Dave - think we need this and this is what it needs to look like - does the implementation do config ipv6 subtrees? (PP: yes) - talking about rev'ing the hosts. should we think of other things we might need before making protocol changes? - Brian Carpenter: - I think we need something like this, but I think we need the overview document as well to describe what else is solved elsewhere and what is not solved - Erik Nordmark: - haven't thought through all the different corner cases - some of the semantics can get hairy - decouple from RIO? - get some adjunct information from the routers, getting configuration information - PP: we want the application to pick the source address and having routing information is important - Steven Barth: - compatibility with default router lifetime? - in a situation with only SADRIOs, we need a consistent way to disable default router lifetime - PP: agree - Alex Petrescu: - don't have a specification for how the host behaves with source address routing selection - which default route would be chosen (for destination or source address)? - OT: this has been addresses in routing area - can we have CIDR on SADR? - Dave Thaler: - host behaviour is something the document needs to cover and the working group needs to agree. - we should adopt this and work on the behaviour. - there are other ways this can work, but this shouldn't hold up a call for adoption - Bob Hinden: - sounds like wg interest exists - should talk to AD(s) - not ready for call for adoption just yet IPv6 Segment Routing Header (SRH), draft-previdi-6man-segment-routing-header, Stefano Previdi, 10 min. ------------------------------------------------------------------- - Stefano Previdi presenting - all together, 3 spring + 6man drafts - define new routing header type, similar to RH0, "SRH" - contains segment list, policy list, HMAC flags - multiple implementations, interoperability demonstrated - adoption? - Brian Carpenter: - worried that this thing inserts headers in the packet en route - not allowed by any other IPv6 specification - Erik Nordmark: - the reason we don't insert header is that it inserts PMTU discovery - encapsulation is preferred - John Brzozowski: - I disagree with Brian and others - we have valid use cases - Lorenzo Colitti: - I don't know that inserting header is fundamentally against IPv6 - currently not allowed, sure - not clear why it couldn't be allowed, assuming established rules - preserve header chain when existing the cloud - MTU is a red herring - we do this today in IPv4 - a solved a problem, not that hard - Erik Nordmark: - it works if you control the environment - you need to make sure ICMP errors don't leak out and go back to the host - if you can do encap you know you've provisioned enough MTU - if you get can ICMP error it will go back to the host - Lorenzo Colitti: - example solution: MUST not emit such error - Bruno: - this is in our charter - we will need some feedback - James Woodyatt: - responding to Brian Carpenter - it's a theoretical concern - the headers your adding can be compressed - I think the idea of adding the SRH but when you insert (...out of time) - Ole Troan: - interest of working on this? - hum, seemed to favor supporting this work IPv6 Segment Routing Security Considerations, draft-vyncke-6man-segment-routing-security , Eric Vyncke, 10 min. ----------------------------------------------------------------- - Eric Vyncke presenting - reworded: - within single ISP - not enable by default - ICMP generation - BCP 38 - RFC 5095 says benign uses of RH0 may be defined using future Routing Header specifications - SRH HMAC coverage - address concerns of RFC 5095 - HMAC requires shared secret (controllar, SR-domain ingress routers) - how to propagate this shared secret is out of scope of this document - Philip Matthews: - within single ISP, but multiple ISPs may want to do this (coordinating administrative domains) - (name unheard) - maybe you need some encryption - source routing header from outside the domain should be trusted? - EV: there should be a trust relationship with the controller -Jen Linkova: - re: topology disclosure - ICMP errors may include the SRH and expose topology - EV: traceroute would show you anyway - Stefano: if we have SRH, should we have a closer look at tools and see what we might need to change (same as MPLS) Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol, draft-ietf-mif-mpvd-ndp-support , Suresh Krishnan, 10 min. --------------------------------------------------------------------- - Suresh Krishnan presenting - info from mif document - mif-mpvd-arch-11 includes IPv6 NDP proposal - generic PVD container - RA can have multiple PVD containers - RS can request specific PVD container info - proposed format - key hash (optional) - pvd_id (currently not specifically defined by mif) - Dave Thaler: - legacy hosts will ignore the container option, like SADRIO - should limit permutations to not explode RA size - Behcet Sarikaya: - maybe we put everything into this container option - Steven Barth: - MTU issues with signatures - we might run into some issues - SK: don't have to have all mpvd info in one RA, can send 1 RA per mpvd container - Christian Heuitema, Microsoft: - draft needs a privacy analysis - a host may disclose pvd ids, which has privacy implications - SK: agree New Individual Drafts -------------------- Current issues with DNS Configuration Options for SLAAC, draft-gont-6man-slaac-dns-config-issues , Fernando Gont, 5 min. --------------------------------------------------------------- - Fernando Gont presenting - RDNSS, DNSSL, with lifetimes - found to be too short - packet loss can cause DNS info to timeout - failure scenario is implementation dependent - propose to change default lifetime value, and semantics - can keep expired info if it's the only info you have - hosts may also use active probing with RSes Transmission and Processing of IPv6 Options, draft-gont-6man-ipv6-opt-transmit , Fernando Gont, 5 min. --------------------------------------------------------- - Fernando Gont presenting - RFC 7045 for IPv6 options - clarify default processing for IPv6 options Improving Scalability of Switching Systems in Large Data Centers, draft-zhang-6man-scale-large-datacenter , Ming Zhang, 5 min. ----------------------------------------------------------------- - Zhang presenting - 2 million IPv6 end hosts - option 1: multiple clusters - option 2: large FIB table on the spine - keep leaf FIBs smaller - propose scale through aggregation - cluster id bits (8 bits) - switch id bits (16 bits) - host id bits (32 bits) IPv6 Flow Label Reflection, draft-wang-6man-flow-label-reflection, Aijun Wang, 5 min. ------------------------------------------------------------------------- - Sheng Jiang presenting - copy received flow label into response - application scenarios described - security concerns: - flow label is untrusted - can be forged - man-in-the-middle attach - consider to be useful only within single administrative domain ------------------------------------------------------------------------- Meeting Adjourned -------------------------------------------------------------------------