9:30 v6ops starts. Chair intro/info space bash: chat about john browzowski's ietf proposal bash: jordi show should start, but will cover happy eyeballs monitoring. happy-eyeballs monitoring after the HEB bis document discussion. John Browzowski - Dashboard.meeting.ietg.org presentation/discussion representing authors for draft () V6 only incremental deployment experiment, with v4 support as necessary. restarting the old v6 only experiment, using v4 help this time. conversation has been ongoing since Seoul meeting, the NOC has been helpful. production hardware and software updates to support v6 only with dns64/nat64 on the main ietf SSID. Looks like ~5% of total use nat64 SSID today... Proposal: "Organize trial nat64/dns64/v6-only SSID for IETF meetings, going forward." Community support is required/wanted here too. jimmartin: all of the SSID's are v6 enabled, there are v6 only. Putting middleboxes in, does seem against our goals though? With other options available, however, this shouldn't be 100% problematic. john: noting that this isn't "breaking" things, there are some bugs which will be found... and we SHOULD be able to do this still. jenlinkova: users sometimes make mistakes in their ssid selection... users CAN use nat64 SSID. warrenkumari: ietf/ietflegacy exist, people CAN just join the nat64 if they want... john: but ietf is the default... so let's move that forward. jordi: i'm pro ipv6, the point though is what? detecting broken apps? john: to make the network 100% usable for all users, to remove barriers to deployment. jordi: Trying to find broken apps/etc, the only way forward is to force the hand, but to do that with some automation, not people. People won't report as often/reliably as we want, automation can though. Extra question, for jim: "how many reports on nat64 network?" jim: 2 tickets open... one from john, one from jordi. wiki page being opened, and feedback to a10 to fix problems as well. lorenzo: disagrees with jim - the only deployment model that's available is the nat64 and dns64. We should move forward, not backwards. We should make sure that the network is supportable and operable, finding systems problems and bugs SHOULD be a goal. jim: key here is: "what is the network objective?" 1) facilitate work by users? 2) ideology and vision? NOC goal is: "making the network work successfully, so people can do their jobs" john: this should be a community decision. don't want to strand folks, always keeping a fallback so users can rollback if required, if things are broken for them. jim: note that the legacy99 SSID shows people CHOOSE the legacy choice. dave@apple: in automating issue detection: "this would be good, but..." apple made some iphone v6 only (no xlat), and tried to build in automated alerting, such that the cell network could know: "send me v4, your v6 is busted" Trying to figure this out is ... hard. very hard. jordi: goal is not detecting the root-cause, but to take some initial packet dumps and use that to debug later. dave@apple: this isn't enough, and operationally this is still quite hard. <>: supportive of moving to this new world. question to jim: "what effort is it to turn off the ietf network in a particular WG session?" jim: This is possible, but this will require coordination (rebooting aps), and there should be note that APs bleed between rooms. : maybe change ietf instead of legacy99? jim: eliminating ietfssid could be the goal? rename to then make users choose... see what they choose? jenlinkova: probably folk are saying: "we are not ready to move" when will we be? what's the bar? warren: this room is a pretty biased group. Find the whole community instead? john: is IAB useful as the representation? joel: got upset about characterizations of changing here... we NEED to ask the community that's where the decision needs to come from. resolution - Fred moved to the nat64 network. Marcus Keane: Turning IPv4 off in an Enterprise network "be nice, this is my first time!" - is corp network engineer/architect - MS ipv6 only enterprise networking - why? status/plans? issues? major challenges? MS enterprise network is ~100 buildings, then three other regions, moving things into the clown NOT local DataCenters. Most remote networks - MPLS vpn served. 800 or so locations, and 1.2m devices, so things move a bit slower at times. Dualstack is enabled everywhere already. Why v6 only? Exhaustion of v4 addresses, overlapping space (acquisitions, azure, etc) complexity of dual-stack... this is hard/expensive. 2 igp, acls, firewals, etc :( sadness iot demands now coming around to get you as well. Testbed deployed, has guest/wired/wireless networks, is opt-in, but plan to make this default 'soon'. Automation of fault detection is rougher than we want. There are problems in dualstack as well. Guest-netowrk issues - on v6only guest .. things SHOULD be simple, they are not. there's also vpn, not just web/mail, bummer. vpns are the devil. Some device problems still exist: rdnss, wireless controller issues, etc. With new building configs, you may be abl eto deploy better/more network/telem etc. you still need better telem than we have, however. Multihoming is a bit more complex here as well. Making tail sites work out is harder. With 'internet first' corp goal, How do you multihome/etc with internal prefix and ISP prefix? Policy routing as a suggested path, however operationally very hard. Source selection is still problematic, still. Drawing slide about networks and displaying the branch office problem. note that hosts will choose the wrong address, at times, which stinks. what if the corp resource is in the AP prefix, not the NA prefix? on, ISP? wrong. :( options evaluated: nat66? hard, not supported yet everywhere. use isp space only - import to your internal network :( your ip space only - requires other resources (public as, ebgp, etc) :( using the mix seems correct. Looking at draft-ietf-rtwg-enterprise-pa-multihoming to help with this problem Also, conditional RA draft-linkova-v6ops-conditional-ras - may help? Really though, the clients must be more intelligent, they are not. (today). Provisioning Domains are required different administrative network domains reachable on the same segment. prefixes, sources and dns zones all would be part of the config here. Image of previous problem, now with 'provisioning domains' shows ra0/ra1 givng routing and dns data to the clients, with nexthop targets dualstack is hard, v6only has to be the goal long term. problems still exist in the v6only world, still need solutions to be found multihoming really has to be sorted out. note that there are v6 stck updates in win10-creator... you should check those out. Questions: ekline: will MS do provisioning domains? thaler: yes lorenzo: "slide with provisioning domains" - we should do this, a lot. multihoming wihtout scalability issues and nat ... are solved here. "What can we do to help?" "What else is missing?" "Are your designs/goals written up? we should do that if not" thaler: "making progress how?" - If you have enterprise networks with this problem - send mail to thaler.. .so more customers and more push behind the solution. jenlinkova: can you share experience with percentusers have to fallback to v4? Was there support problems? marcus: we enabled v6 only for particular product gruops and IT. we are more inclined to work through problems, other groups may not be? timchown: node-requirements doc should be including 5.5 support text. is this wrong? should we add something else? jenlinkova: dhcp can't do this, RAs are the only place to do this correctly lorenzo: no such methods from myth? thaler: maybe 5.5 should still be included ... lorenzo: not that 5.5 is a hack, but that relying on 5.5 for this is hacky. Vaibhac Bajpai: A Longitudinal View of Dual-stacked Websites: Failures, Latency and Happy Eyeballsk joint work with samknows folks There's less study on v6 performance, lots of study on adoption. since 2013 this study has run to try and show v6 performance. at start 1% (by google numbers) now ~15%! utilize samknows probes (about 100) from 66 origin asns. most measurement from residential networks Drift of v6 deployment is increasing, mostly on weekends though. teredo and relays usage is dropping. notes about blacklisting efforts for v6 nodes, some prefixes will not get v6 AAAA answers from (at least) google. largely in japan/malasyia, peru - btw. adoption at the server-side is increasing, notable events at: w6d, w6ld, cloudflare publishing v6. (last was HUGE - 10% of alexa1M) Failure types, sometimes failures are silent, because happy-eyeballs. will be useful for v6only netowrks. Results: complete failures - alexa1m graph looks the same as the adoption graph. 40% in 2009, 3% today. alexa ranking for the 3% failures, are in the 100k rank... less popular sites tend to be more faliure prone. 6 most popular, and less than 100 on rank, still fail,why? bing.com, detick.com, engadget.com, nifty.com, qq.com, sakura.ne.jp ... monitoring for aaaa, rquired as providers tend to add/remove aaaa over time. sites from w6ld have disappeared, maybe the site is just gone? (v4 and v6 broken) 1% 8% v6 only. Partial failures: notes about even after w6ld, still sites which have aaaa have v6 failures root-cause can be: not having aaaa in dns? css, javascript, images .. often these come from in-domain other sites without AAAA. these will be broken pages in v6 only networks. same-origin and cross-origin examples discussed. sometimes this is the CDN nothaving all AAAA for all parts of the sites. Latency: over time, v6/v4 have become equivalent, or closely so. initially missing CDN v6 support could have been the cause. Today's latency state: 40% are v6-faster 94% are ~1ms slower mostly large-cdn providers are v4/v6 enabled, showing these results. Happy Eyeballs numbers: (where HE timeout was a factor) many v6 prefer over v4. sometimes this is even when v6 is slower. pushing back into ietf a timer change for HE, move from 300ms to 150ms. dave@apple - want input for 6557 bis update. jordi: 1) samknows no longer uses tplink, can the HE monitoring code still work? presenter: yes, still works fine. jordi: 2) only 1% latency increase over 100ms? presenter: no bias, generally native only... tunnelbroker stuff should be outliers... jordi: 3) only HE is being monitored? presenter: yes. stevenstros: measuring content on yahoo on v6 is mostly 'actual content' with ads slower... which is why failures for yahoo were shown this way. leehoward: previous experience shows that in fact with no v4 .. no ads. there was a 150ms proposal, this sounds like a point-in-time number. should this be something that is more responsive? or will it stay constant? presenter: the timer here is 'when we can disable v4' - when HE timer is 0, no v4 required. dave@apple: apple uses some other measure to do the timeout value... apple has been increasing the timer, not decreasing. because they want to prefer v6... over v4. presenter: questions about HE timers purpose. dave@apple: increasing forever is silly. but making it to ~500ms, that might be useful, still. lorenzo: 300ms was chosen because 250ms timer also existed. the intnetion was for the choice to prefer v6, but still make things work for users. setting the timer to 0 means 50% ipv4 usage... Lee howard: IPv6 Deployment Status 'state of v6-only' ? Total adoption (to google perspective) == 20% ish. Pay attention to the weekend jump - enterprises are lagging. network operators deployments still doing well. interesting skew in numbers per country... sept 2019 we may have 50% coverage! woot! notes about US based deployment - showing some 90+% ... but with bad performance? noting some facts about v6 only asns? there may be parallel v6 as and v4 as? v6 only initiatives - many folk talking... there's still going to have to be translation services. reasons for v6 - simplicity, cost, etc. summary: enterprises lag :( jenlinkova: data for locale ... lorenzo: the weekend swing is .. hard to explain. 2018 could be the 50%? george: 2021 could be the 50%? jordi: predicts 2020 70% ... mikael: v6only networks aren't really v6 only. RussWhite: Requirements for IPv6 Routers draft-ietf-v6ops-ipv6rtr-reqs-00 Outlines of changes... Lots of new text on ZTP. DHCPv6 required as well as SLAAC Needs data/support on DDoS requirements too. next-step: more comments/suggestions please. daveplonka: invite to thur meeting - about icmp limiting discussion. jameswoodyatt: doc should use more suggestions: "should this also talk about 7934? multiple-address support?" lorenzo: on dhcpv6 requirement - client ? server? this should be more clear... Dave Schinazi: Happy Eyeballs Version 2: Better Connectivity Using Concurrency Main differences to fix in new draft: asynchronous DNS problems. AAAA and A queries have to go out and get back before tcp starts. new doc: fire tcp as soon as dns returns, for each family individually. also include some limits on how long to wait for dns replies. (50ms) include some new rules as well for address-selection algorithm. prefer based on rtt as well? new section on nat64/dns64 there are 3 issues to deal with here: 1) ipv4 literals - synthesize v6 addr. 2) hostnames with buxted AAAA - wait ~2s, then query A and move forward. 3) vpn with dns tunneling - do the literals trick, basically. (see doc/slids) limitations: PMTUD - HE can't know this, since it ends with syn/synack/ack. application-layer operational issues next steps: addressed/ing comments apple implementation deployed wglc question? (is there more feedback or?) jordi: tracking mss, is that a thing you should do? (for pmtud problems) lorenzo: mikael: pmtud discussion - was there feedback from content folk about how extra-load/etc HE caused? nabil: timer questions - 15ms is this based on some sciencey thing? or? dave@apple: we used empirical data from real devices in the field. science! thaler: this doc should be std track. 13:30 Thursday 20 July 2017 -- Reporting of Happy Eyeballs v2 Failures 2017-07-03, Jordi Palet Martinez Fred Baker: We don?t define protocols here. This belongs wherever syslog work belongs. Waren Kumari: Asking for a well-known anycast address is not really defining a protocol. Eric Vyncke: What is the incentive for anyone to implement and/or deploy this? Ondrej Caletka: This won?t work without NAT64 Jordi Palet Martinez: This does not need NAT64 or DNS64 Ondrej Caletka: This will interact badly with lingering uses of 6to4 Jordi Palet Martinez: But 6to4 is deprecated Waren Kumari: That doesn?t mean no one is still using it Waren Kumari: There?s a big DOS vulnerability here Jen Linkova: I see very limited use for this. Perhaps within an enterprize network. David Schinazi: Syslog messages of IPv6 failures may have serious privacy implications Private web browsing may not be private if your client device is logging failures into an unknown syslog server We should not try to integrate this into RFC6555bis; RFC6555bis document is almost done; this still has a long way to go Mikael Abrahamsson: The idea here sounds useful, but there are a lot of details to work out -- Considerations For Using Unique Local Addresses 2017-03-13 , Bing Liu Merike Kaeo: Why are we even discussing ULAs? Fred Baker: A ULA is a firewall rule implemented in BGP I don?t understand the opposition to ULA Lorenzo Colitti: ULA can create a false sense of security If you?re on an adjacent network, just because I don?t advertise a route doesn?t mean you can?t send a packet to me Erik Kline: Good that the document states that ULA addresses are not RFC 1918 addresses Document needs to say ULA + NPTv6 is ?not recommended? or ?NOT RECOMMENDED? Tim Chown: Many people do seem to use ULA without trouble. Ronald Bonica: This document can be shortened to just a couple of pages. Victor Kuarsingh: I agree: Document needs to say ULA + NPTv6 is ?not recommended? or ?NOT RECOMMENDED? Lorenzo Colitti: Lots of existing walled gardens work fine using GUA global addresses Tim Chown: UK universities are creating ULAs manually, instead of including the random part Victor Kuarsingh: I agree with Lorenzo. Marcus Keane: We find it?s better to use GUA global addresses instead of ULAs -- Using Conditional Router Advertisements for Enterprise Multihoming 2017-06-14 , Jen Linkova Fred Baker: I?m trying to work out how to implement this Timothy Winters: Why not use route information options? Jen Linkova: Not all platforms support RIO David Lamparter: I support this and plan to implement it Do the policy rules need to include more than just checking the routing table? Tim Chown: Could some external device monitor the network and send commands to the routers? Jen Linkova: It?s better if the routers do this detection for themselves Lorenzo Colitti: It is useful for us to document the current behaviors of today?s hosts which may have software from ten years ago. This is what operators need to know. Waren Kumari: Most implementations do VRRP tracking already, so this could be done in a similar way. Thaler: What if both uplinks are down? Leave both deprecated. Both addresses still exist; they?re just not preferred. Mikael Abrahamsson: There is prior art here. RFC 7084 talks about what to so when WAN link goes down. The Homenet code already does something like this. Timothy Winters: We should add RIO too, for future hosts that support RIO. Mikael Abrahamsson: I would like to see more work on the control plane Jen Linkova: This mechanism is independent of the control plane that controls it Darren Dukes: How fast is the propagation? Jen Linkova: That?s hard to say right now because of vendor bugs. Pierre Pfister: I support this. This work is compatible with RFC 7084 and Homenet work. Lorenzo Colitti: Helping to get vendor bugs fixed is a good reason to publish this. David Schinazi: I like this work and support it. Fred Baker: Call for hum on adoption Reject outright? Silence Consider later? Weak hum Adopt now? Strong hum -- Requirements for a Zero-Configuration IPv6 CPE 2017-06-17, Fred Baker Bob Hinden: The router I have is less of a horror story Timothy Winters: We should make having IPv6 enabled by default a requirement for using the ?IPv6ready? logo Barbara Stark: The only significant IPv6 success stories are when the ISP provides its own home gateway, already configured correctly Jordi Palet Martinez: Look at RFC 8026 Lorenzo Colitti: The document is overly detailed. We want implementers reading and complying with RFC 7084. Hans Liu: D-Link is working to improve this issue Victor Kuarsingh: I have never seen a router that comes with IPv6 enabled John Jason Brzozowski: We should include a specification of what a router should do if it gets no IPv4 address. Joseph Abley: D-Link currently has a line of 31 different home gateway models, all with IPv6 enabled by default Barbara Stark: AT&T-supplied home gateways do IA PD. Mark Townsley: D-Link was involved with World IPv6 Launch in 2012. Initiatives like that are needed, not only more RFCs. Fred Baker: What are next steps? Sorten the document? No specific actionable conclusion was reached. -- RFC 7984-bis in four parts Basic Requirements for IPv6 Customer Edge Routers 2017-06-12 , Transition Requirements for IPv6 Customer Edge Routers 2017-06-12 , Minimum Requirements for IPv6-only Customer Edge Routers 2017-06-11 , Basic Requirements for IPv6 Customer Edge Routers with HNCP 2017-06-11 , Jordi Palet Martinez Barbara Stark: We should be wary about updating RFC 7084 unless we really need to Timothy Winters: S-2 (ingress filtering) was a ?MUST? in RFC 6204, but got downgraded to ?SHOULD? in RFC 7084. We should revert that to ?MUST? Mikael Abrahamsson: I agree with Barbara Stark. We should not update RFC 7084. We should have a new RFC for transition mechanisms.