idnits 2.17.1 draft-palet-v6ops-he-reporting-00.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 : ---------------------------------------------------------------------------- == There are 3 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 81: '... ([RFC5424]) over UDP ([RFC5426]), MUST be used, by means of the...' RFC 2119 keyword, line 87: '...e this reporting MUST configure at lea...' RFC 2119 keyword, line 92: '...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 (October 28, 2017) is 2371 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Palet Martinez 3 Internet-Draft The IPv6 Company 4 Intended status: Standards Track C. Martinez 5 Expires: May 1, 2018 LACNIC 6 October 28, 2017 8 Reporting of Happy Eyeballs Failures 9 draft-palet-v6ops-he-reporting-00 11 Abstract 13 This document describes an extension to Happy Eyeballs in order to 14 report IPv6 failures that force the fall-back to IPv4 and 15 consequently, facilitate the troubleshooting of IPv6 networks. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 1, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Using Syslog . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Discovery of the syslog collector NSP . . . . . . . . . . . . 3 54 4. HE behaviour on failure detection . . . . . . . . . . . . . . 3 55 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 3 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 Happy Eyeballs ([RFC6555]) provides a way for improving user-visible 65 delay when IPv6 connectivity is performing worse than the IPv4 one. 67 However, this hides the possible IPv6 connectivity issues to the 68 operator because users don't notice anything broken, so they aren't 69 reporting it to their providers. 71 The goal of this document is to specify an extension of HE, in order 72 to use existing protocols for providing a reporting to the operator, 73 which can be used to setup alarms and trigger further investigation 74 so to improve network reliability, facilitating the detection of 75 failures as soon as they appear, without the need of external 76 monitoring. 78 2. Using Syslog 80 In order to simplify the reporting of the HE failures, syslog 81 ([RFC5424]) over UDP ([RFC5426]), MUST be used, by means of the 82 default port (514) with IPv6-only. 84 The intend is to make this reporting very simple, so no choice of 85 alternative ports or transport protocols is offered. 87 Operators willing to use this reporting MUST configure at least one 88 syslog collector at the IPv6 prefix formed as: 90 Network-Specific Prefix::192.88.99.1 92 The Network-Specific Prefix (NSP) MUST be chosen by the operator from 93 its RIR allocated IPv6 addressing space. 95 Additional collectors can be made available by using anycast at the 96 NSP + 192.88.99.0/24 prefix 98 3. Discovery of the syslog collector NSP 100 The same mechanism described by RFC7050 ([RFC7050]) should be used to 101 define the address of the syslog collector(s). 103 Because the collectors will be using an IPv6 address with the 32 low 104 order bits from the reserved range 192.88.99.0/24, this will not be 105 in conflict with any public addresses used in Internet, so this 106 mechanism is compatible with the expected usage of the NSP for NAT64. 108 4. HE behaviour on failure detection 110 This section will specify the exact behaviour of HE in order to 111 initiate the reporting and the specific format/parameters of the HE 112 failure message to be sent to the syslog collector. 114 A preliminary consideration is to include, in addition to the syslog 115 required parameters, the timeouts detected, the failed destination 116 address and the source prefix from where the destination has failed. 118 TBD. 120 5. Privacy Considerations 122 The goal is to provide the operator information about the failures 123 detected by HE, without requiring specific users traffic information. 124 Towards this, it will be sufficient to provide to the syslog 125 collector details about the failed destination address and source 126 prefix. So privacy issues regarding identification of a specific 127 device or users are avoided. 129 Nowadays, operators already log this information in order to comply 130 with lawful interception regulations, and in general, data protection 131 regulations allow this logging when technically required. Data 132 protection regulations explicitly say that the data can't be 133 disclosed, and there is no need to do so. 135 In general, vendors also collect telemetry data from devices, in 136 order to improve OSs and in some situations, there are regulations 137 that enforce offering the user to enable/disable that feature. So we 138 could consider offering the same feature for this mechanism. 140 When the mechanism described in this document detects a failure, the 141 operator will need to find if the problem is related to: 143 o A specific user (inside the customer local networks, or even at 144 their WAN router). 146 o A group of users (e.g., one or several part of the access or 147 distribution networks). 149 o The entire operator network (e.g., core network or transit router/ 150 s). 152 o The destination network. 154 o Somewhere else in the path to the destination (e.g., transit 155 providers). 157 Those cases, in terms of privacy considerations, will fall into one 158 of the following categories: 160 a. Failure cause is internal to a specific customer (LANs or router/ 161 s): The operator may decide, depending on their country 162 regulations and services offered to that customer, to inform the 163 customer (and decide what information is provided), or ignore the 164 failure and include it in a "while list" (i.e., list of "don't 165 care" failures), so the monitoring system doesn't keep providing 166 alerts on it. 168 b. Failure cause is due to the operator network: The operator will 169 need to find the cause and fix the failure, without disclosing 170 any personal data. 172 c. Failure cause is due to third parties: The operator don't need to 173 disclose any specific user source address/prefix, because in this 174 case, the shorter prefix (typically the RIR allocated prefix or 175 part of it, when is being announced split among different BGP 176 peers), from which the failure has been verified. 178 In the most extreme case, a more restrictive usage of this procedure, 179 not involving logging any user source address/prefix, will be to log 180 only the failed destination address. In a big percentage of the 181 cases, it will be enough for the operator to detect the failure, as 182 experience shows that HE fall-back occurs mainly because path or 183 destination misconfiguration or issues. So, the ISP could replicate 184 the failure from any other source address in its network to the same 185 failed destination. If we take this approach, failures internal to a 186 specific customer, could not be reported by the operator to the 187 customer (as there is no source data logging), and together with 188 partial failures of the operator network will require extra work from 189 operator's staff to research the cause of the failure (i.e., it is in 190 my network, part of it, a specific customer or external). 192 So, there is no distinction between the privacy issues from this 193 protocol compared to regular network operation, abuse reporting, etc. 195 6. Security Considerations 197 This document does not have any specific security considerations. 199 7. IANA Considerations 201 IANA is requested to reserve 192.88.99.0/24 for this RFC, which was 202 previously released by ([RFC7526]). 204 8. Acknowledgements 206 The author would like to acknowledge the inputs of TBD ... 208 9. Normative References 210 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 211 DOI 10.17487/RFC5424, March 2009, 212 . 214 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 215 RFC 5426, DOI 10.17487/RFC5426, March 2009, 216 . 218 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 219 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 220 2012, . 222 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 223 the IPv6 Prefix Used for IPv6 Address Synthesis", 224 RFC 7050, DOI 10.17487/RFC7050, November 2013, 225 . 227 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 228 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 229 DOI 10.17487/RFC7526, May 2015, 230 . 232 Authors' Addresses 234 Jordi Palet Martinez 235 The IPv6 Company 236 Molino de la Navata, 75 237 La Navata - Galapagar, Madrid 28420 238 Spain 240 Email: jordi.palet@theipv6company.com 241 URI: http://www.theipv6company.com/ 242 Carlos Martinez 243 LACNIC 244 Rambla Republica de Mexico, 6125 245 Montevideo 11400 246 Uruguay 248 Email: carlos@lacnic.net 249 URI: http://www.lacnic.net/