idnits 2.17.1 draft-xie-v6ops-network-happyeyeballs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([NHE-GitHub], [RFC8305]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 314: '... ([RFC5424]) over UDP ([RFC5426]), MUST be used, by means of the...' RFC 2119 keyword, line 320: '...e this reporting MUST configure at lea...' RFC 2119 keyword, line 331: '...fic Prefix (NSP) MUST be chosen by the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 25, 2018) is 1978 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Xie 3 Internet-Draft China Telecom 4 Intended status: Informational L. Song 5 Expires: May 29, 2019 Beijing Internet Institute 6 J. Palet Martinez 7 The IPv6 Company 8 November 25, 2018 10 Network-side Happy Eyeballs based on accurate IPv6 measurement 11 draft-xie-v6ops-network-happyeyeballs-01 13 Abstract 15 During the period of IPv6 transition, both ISPs and ICPs (Internet 16 Content Providers) care about user's experience in dual-stack 17 networks. They hesitate to provide IPv6 to their users due to the 18 fear of poor IPv6 performance. Network-based Happy Eyeballs (NHE) is 19 proposed in this memo as an approach to facilitate ISPs to identify 20 IPv6 connectivity issues and provide better connectivity to end 21 users. NHE does accurate measurements and comparison on IPv6/IPv4 22 performance on the network side compared with client-side as in Happy 23 Eyeballs v2 (HEv2) [RFC8305]. It works independently with client's 24 adoption of HEv2 and both coexist without conflicting. 26 REMOVE BEFORE PUBLICATION: The source of the document with test 27 script is currently placed at GitHub [NHE-GitHub]. Comments and pull 28 request are welcome. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 29, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Overview of NHE Framework . . . . . . . . . . . . . . . . . . 3 66 3. IPv6/IPv4 Performance Measurement . . . . . . . . . . . . . . 4 67 3.1. Performance metrics . . . . . . . . . . . . . . . . . . . 4 68 3.2. Location of IPv6/IPv4 Measurement . . . . . . . . . . . . 6 69 3.3. Reducing measurement traffic . . . . . . . . . . . . . . 7 70 4. Reporting IPv6 failures using syslog . . . . . . . . . . . . 7 71 4.1. Discovery of the syslog collector NSP . . . . . . . . . . 8 72 5. One Use Case of Troubleshooting action . . . . . . . . . . . 8 73 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 During the period of IPv6 transition, both ISPs and ICPs (Internet 82 Content Providers) care about user's experience in dual-stack 83 networks. They hesitate to provide IPv6 to their users due to the 84 fear of poor IPv6 performance. Happy Eyeballs v2 (HEv2) [RFC8305] 85 provides an approach to enable clients to attempt multiple 86 connections in parallel. It is helpful to work around the blocked, 87 broken, or sub-optimal network. Taking IPv6 priority consideration 88 in design, HEv2 helps increase IPv6 traffic in networks and reduce 89 the delay in client side as well if IPv6 connectivity is poorer. So 90 far, most modern web browsers support HEv2 very well, thanks to 91 popular web browser engines, such as WebKit and Trident. However, in 92 practice there are still some barriers keeping Mobile developers who 93 develop Apps with APIs and libs which don't not implementing HEv2. 95 Firstly, HEv2 adds additional complexity and uncertainties to both 96 development and operation. For example, according to the section 8 97 of [RFC8305] there are 6 Configurable values such as Resolution Delay 98 and Connection Attempt Delay. It raises a bar for small application 99 developers to do a "nuanced implementation" to tune these values 100 according to network dynamics. Secondly, paralleled connections 101 emitted by HEv2 produces larger volume of traffic which consume both 102 mobile fees and power. As a result, mobile application developers 103 may choose not to adopt HEv2 or postpone their IPv6 transition due to 104 those issues. The third, client-based HEv2 hides some of the 105 possible IPv6 connectivity issues to the operator, because users 106 don't notice anything broken, so they aren't reporting it to their 107 providers. Those issues are more notable in regions where IPv6 108 performance is not as good as IPv4 in terms of RTT and failure rate 109 [APNIC-v6perf]. 111 This memo is intended to proposed a Network-side Happy Eyeballs 112 (NHE), an approach to improve IPv6 connectivity by doing network-side 113 IPv6 measurement and failure reporting. Instead of requiring the 114 client to race IPv6 and IPv4 connections, NHE intends to do the 115 "race" on the network side. NHE aims to provide helpful alert 116 information for ISP to fix the networking issues by themselves. In 117 addition, this memo also introduces a potential use case of NHE to 118 work around networking issues which can't be resolved locally (issues 119 of third parties on the path to the destination, or the destination 120 itself, for example). 122 The rationale of NHE approach is simple. Considering that ISPs 123 typically the mobile and broadband network providers have more 124 resources, capability and motivation to do accurate IPv6/IPv4 125 performance measurement, using existing protocols for the immediate 126 alert/reporting of failures, those can then be analyzed and resolved, 127 improving network reliability, for the good of their users. With 128 sufficient and accurate troubleshooting information, ISPs will have a 129 crystal clear vision about their IPv6 network performance and spare 130 no effort to improve it. 132 2. Overview of NHE Framework 134 As shown in Figure 1 NHE Frame consists of three key components: 135 IPv6/IPv4 performance measurement, IPv6 failure reporting and 136 troubleshooting actions on these failures. To resolve the issue of 137 Client-based HEv2 concealing the operational issues of IPv6 network, 138 IPv6 failure reporting is a key element in NHE, by reporting and 139 collecting precise performance information of the IPv6 network. Note 140 that IPv6 failure event is not necessary only triggered by 141 disconnection or severe packet dropping. It includes all events once 142 IPv6 connection is slower than IPv4 in the race. Section 4 will 143 introduce more about how IPv6 failure reporting works. 145 The IPv6/IPv4 performance measurement component is designed to feed 146 IPv6 failure reporting, by performing IPv6/IPv4 RTT measurement on a 147 special list of domains (called measuring list). The list of domains 148 under the measurement can start with a well populated cache, then 149 updated in alignment with a certain dynamic popularity of Domains in 150 the network. To achieve better accuracy of measurement, probes may 151 be located adjacent to clients on the edge of the network. The 152 criteria of putting a specific domain into that list and how to 153 perform the measurement are introduced in Section 3. 155 +-------------+ +--------------+ +---------------+ 156 | IPv6/IPv4 +---> | IPv6 Failure +---> |Troubleshooting| 157 | Measurement | | Reporting | | Actions | 158 +-------------+ +--------------+ +---------------+ 160 Figure 1: High-Level NHE Framework 162 After IPv6 failure information is collected and analyzed, various 163 troubleshooting actions can be adopted accordingly. Most of the 164 actions are similar to IPv4 network troubleshooting. For example, if 165 the problem is local, operators should resolve the networking issue 166 as soon as possible. If the problem is caused by far-end or third- 167 parties, the ISP may check the upstream ISPs or transit peering ASs 168 to clear the issue (withdraw some BGP peerings for example). There 169 is a case with an action which can be adopted temporarily to reduce 170 the suffering of IPv6 poor performance for a specific domain. It 171 will be introduced in Section 5. 173 Note that NHE can work independently with client's adoption of HEv2 174 and both coexist without conflicting in the NHE framework. 176 3. IPv6/IPv4 Performance Measurement 178 An accurate IPv6 performance measurement is vital to the success of 179 NHE. An accurate measurement depends on what to measure, where and 180 how to measure. 182 3.1. Performance metrics 184 In client-side HEv2, a kind of round-trip delay or round-trip 185 time(RTT) metric is used where a race between IPv6 and IPv4 186 connection is measured, starting from the domain name resolution, 187 then the TCP setup on both address families. In NHE, a similar 188 approach is adopted in the ISP network to simulate a client doing a 189 race for a list of domains. 191 o Lookup the domain name. If a positive AAAA response with at least 192 one valid AAAA record is received, it continues the process. If a 193 negative response with no AAAA record is received, it will break 194 and continue with another domain in the list. Note that, if a 195 negative response with ServFail is received, which means error on 196 the far-end server, it should be marked "alert to operator" to 197 report "ServFail" incident. It is observed that some clients will 198 continue asking AAAA queries after receiving ServFail response. 200 o Make TCP connections via all IPv6 and IPv4 destination addresses 201 returned. Note that in NHE there is no address sorting or 202 connection attempt Delay which are important in the design of 203 client-side HEv2. NHE measuring server can concurrently make 204 connections on all addresses returned. 206 o The round-trip delay is measured including the RTT of the domain 207 name resolution and the RTT of the TCP setup (started when sending 208 the SYN and ending when the ACK is received). If there is more 209 than one IP address in either the AAAA or A record responses, all 210 the addresses should be measured for the round-trip delay. 212 o Calculate the difference of round-trip delay (Diff-RTT) of 213 different address families. If there are more than one IP address 214 in either the AAAA or A record responses, the minimum RTT of a 215 destination from one address family will be chosen to do the 216 difference, that is Min(RTT-IPv6)-min(RTT-IPv4) 218 o For each domain, if the difference of the round-trip delay of IPv6 219 and IPv4 is larger than a configurable threshold, the domain will 220 be recorded in a local list and flagged as "alert to operator" 221 with "Poor IPv6 Performance" incident. This action will trigger 222 the reporting algorithm (described in section 4). If the domain 223 is already listed in the local list with a flag "alert to 224 operator", nothing should be done (in order to avoid repetitive 225 alerts). 227 o When a follow-up measurement result shows that, for a given 228 domain, which was previously flagged as "alert to operator", there 229 is no longer an issue, the "alert to operator" flag must be 230 cleared and the reporting algorithm will be triggered. 232 Note that the threshold value should be tunable by the network 233 provider to gain a better tradeoff between IPv6 vs IPv4 performance 234 and allow to adjust the IPv6 vs IPv4 priority local policy. 236 In the measurement process described above, there is an important 237 domain list called Measuring list which contains the targeted 238 domains. The list can be formed and updated from the popular domains 239 visited by users of the network. This measurement should be done 240 periodically on each domain, every a given configurable number of 241 hours. 243 Compared to Client-side HEv2, NHE operated by ISPs have more 244 resources to do better performance measurement. For exmaple, the 245 race on the handset measures the round-trip delay on one 246 instantaneous connection which does not fully represent the 247 connectivity performance of one address family in a persistent 248 period. For example, erratic variation in delay (caused by network 249 jitter) makes it difficult to support many interactive real-time 250 applications. So, the statistics of round- trip delay are helpful 251 for ISPs to build more sophisticated measurements. Section 4 of 252 [RFC2681] specifies some statistics definitions for round-trip delay 253 which can be utilized for advanced Round-trip delay measurement, such 254 as percentile, median, minimum, inverse percentile, etc. 256 Also, HEv2 measurements may be influenced by access network problems, 257 which don't affect NHE measurements. The ISP should measure the 258 access network problems using alternative means. 260 3.2. Location of IPv6/IPv4 Measurement 262 According to the accuracy requirement of user performance simulation, 263 the location where the measurement is done is very important. The 264 intuitive approach is to place the measuring probes or servers on the 265 edge, in proximity to the end users. In 4G LTE cellular networks as 266 a typical case, the performance measurement servers can be located in 267 proximity to base stations (or an aggregation point). There is only 268 at most one hop difference in the end-to-end path between a real end- 269 user and a destination. 271 In the case of broadband networks,the measuring probes can be 272 collocated with the BRAS, OLTs, or equivalent aggregation points, 273 depending on each access technology. 275 Setting up probes at different parts of the network, including core, 276 or close to the upstream provider connectivity, can help to determine 277 the source of the issues, especially if they affect many domains. 279 Moreover, probes can be designed into a special mobile device for 280 reporting purpose. There are many choices. For example, people can 281 implement a specially application to do the probing and reporting to 282 a collector operated by the operator. Modern APM (application 283 performance measurement) and NPM (network performance measurement) 284 technologies allow normal application software integrated with 285 special SDK (Software Development Kit) for measuring purposes. So, 286 it is possible for mobile App providers to adopt NHE framework to 287 avoid IPv6 poor performance by themselves, although the 288 troubleshooting actions are different from the one on the ISP case. 290 3.3. Reducing measurement traffic 292 Since the IPv6/IPv4 performance varies per domain, there is a fear of 293 having to generate a lot of measuring traffic in NHE. There are two 294 approaches that may be helpful to generate less traffic. One is to 295 keep a moderate size of Measuring list list including, for example, 296 the top 1k popular domains in the cache. The size of the Measuring 297 list can be configurable as well according to the ISP local 298 policy.One optional approach to limit the size of the measuring list 299 is to focus on top 1k Apps other than domains. ISPs can cooperate 300 with ICPs to maintain a domain list of top Apps for NHE. 302 The second approach to reduce the measurement traffic, is to use 303 passive measurements. The round-trip delay of DNS lookup of a 304 particular domain is trivial in most of the cases if there is a cache 305 hit. So passive measurement should focus on monitoring TCP 306 connection of specific destinations. Suppose there are 1000 top 307 popular domains in the measurement list, which means a thousand of 308 TCP connections will be inserted into the passive monitoring to 309 measure the round-trip delay. 311 4. Reporting IPv6 failures using syslog 313 In order to simplify the reporting of the NHE failures, syslog 314 ([RFC5424]) over UDP ([RFC5426]), MUST be used, by means of the 315 default port (514) with IPv6-only. 317 The intent is to make this reporting very simple, so no choice of 318 alternative ports or transport protocols is offered. 320 Operators willing to use this reporting MUST configure at least one 321 syslog collector. 323 The configuration can be done in a static way, providing dedicated 324 IPv4/IPv6 addresses for the syslog collectors and probes. 326 As an alternative, a more automated procedure can be done by 327 configuring at least one syslog collector at the IPv6 prefix formed 328 as: 330 Network-Specific Prefix::192.88.99.1 331 The Network-Specific Prefix (NSP) MUST be chosen by the operator from 332 its RIR allocated IPv6 addressing space. 334 Additional collectors can be made available by using anycast at the 335 NSP + 192.88.99.0/24 prefix 337 Note that messages encoded in syslog are to be defined. As 338 introduced in Section 3.1, syslog of NHE should contain two kinds of 339 message to report "Poor IPv6 Performance" incident and "ServFail" 340 incident. 342 4.1. Discovery of the syslog collector NSP 344 In case the automated procedure is used, the same mechanism described 345 by RFC7050 ([RFC7050]) should be used to look for the address of the 346 syslog collector(s). 348 Because the collectors will be using an IPv6 address with the 32 low 349 order bits from the reserved range 192.88.99.0/24, this will not be 350 in conflict with any public addresses used in Internet, so this 351 mechanism is compatible with the expected usage of the NSP for NAT64. 353 5. One Use Case of Troubleshooting action 355 Besides the normal network troubleshooting measures taken by network 356 operators as usual in IPv4 networks, there are other troubleshooting 357 actions for temporary but urgent workarounds. 359 Before [RFC6555] and [RFC8305] were documented, selective filtering 360 of the DNS AAAA record (returning NODATA) was proposed as a practice 361 making the IPv6 transition less painful [Less-painful]. The basic 362 idea introduced is that ISP DNS Recursive servers does not return 363 AAAA for users who have broken IPv6 connectivity. There are some 364 working implementations of such filter AAAA option in BIND 9 365 [Filtering-AAAA]. 367 However, it should be noticed that there are two security risks on 368 selective filtering. One is that it may break DNSSEC and omit RRSIG 369 records covering type AAAA as well as AAAA record. The second is 370 that filtering AAAA records cause DNS incoherency in the end-users 371 perspective which may causes some risks if end user's application 372 depend on the integrity of DNS data. 374 To reduce both security risks, an alternative approach for an ISP 375 using NHE, could be to run a special resolver which artificially 376 delays the AAAA answers of a targeted domain name. A domain name 377 being targeted means that the IPv6 performance of that domain name is 378 measured and reported with poor performance. So, instead of 379 filtering the AAAA record, postponing the AAAA responses with a 380 configurable timer (i.e., 300 ms) may cause IPv6 connection losing 381 the race on the client side which avoid Concurrent IPv6 and IPv4 382 connection attempts. It will help the HEv2 client. The non-HE 383 client will fall back sooner to IPv4 without IPv6 connections and 384 retries. 386 Note that there is a corner case when negative response with ServFail 387 are received for a domain name lookup, no ServFail response should be 388 returned to the client, because it is observed that some clients will 389 continue querying for AAAA RRs after receiving ServFail response. In 390 this case, the resolver could silently drop the query without 391 responding to the client. 393 6. Security considerations 395 TBD 397 7. IANA Considerations 399 No IANA considerations for this memo 401 8. Acknowledgments 403 Acknowledgments are given to Geoff Huston, David Schinazi, Marc 404 Blanchet, and Paul Vixie who gave comments and suggestions on the 405 conception of NHE. 407 Thanks to Tony Finch and Tommy Pauly who gave positive comment on the 408 part which 01 version stands on. 410 9. References 412 [APNIC-v6perf] 413 APNIC, "APNIC IPv6 Performance Monitoring", 414 . 416 [Filtering-AAAA] 417 "Filter AAAA option in BIND 9", August 2017, 418 . 420 [Less-painful] 421 Yahoo, "IPv6 and recursive resolvers:How do we make the 422 transition less painful?", March 2010, 423 . 425 [NHE-GitHub] 426 BII, "GitHub Repository of Network-side Happy Eyeballs", 427 . 430 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 431 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 432 September 1999, . 434 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 435 DOI 10.17487/RFC5424, March 2009, 436 . 438 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 439 RFC 5426, DOI 10.17487/RFC5426, March 2009, 440 . 442 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 443 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 444 2012, . 446 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 447 the IPv6 Prefix Used for IPv6 Address Synthesis", 448 RFC 7050, DOI 10.17487/RFC7050, November 2013, 449 . 451 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 452 Better Connectivity Using Concurrency", RFC 8305, 453 DOI 10.17487/RFC8305, December 2017, 454 . 456 Authors' Addresses 458 Chongfeng Xie 459 China Telecom 460 No.118 Xizhimennei street, Xicheng District 461 Beijing 100035 462 P. R. China 464 Email: xiechf.bri@chinatelecom.cn 465 Linjian Song 466 Beijing Internet Institute 467 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA 468 Beijing 100176 469 P. R. China 471 Email: songlinjian@gmail.com 473 Jordi Palet Martinez 474 The IPv6 Company 475 Molino de la Navata, 75 476 Madrid, La Navata - Galapagar 28420 477 Spain 479 Email: jordi.palet@theipv6company.com 480 URI: http://www.theipv6company.com/