<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc category="std" submissionType="IETF" consensus="yes" docName="draft-palet-ietf-v6ops-he-reporting-00">
  <front>
  <title abbrev="HE Failures Reporting">Reporting of Happy Eyeballs v2 Failures</title>

    <author fullname="Jordi Palet Martinez" initials="J" surname="Palet Martinez">
      <organization>Consulintel, S.L.</organization>

      <address>
        <postal>
          <street>Molino de la Navata, 75</street>

          <city>La Navata - Galapagar</city>

          <region>Madrid</region>

          <code>28420</code>

          <country>Spain</country>
        </postal>

        <email>jordi.palet@consulintel.es</email>

        <uri>http://www.consulintel.es/</uri>
      </address>
    </author>


    <date year="2017"/>

		<workgroup>v6ops</workgroup>


		<abstract>
			<t>This document describes an extension to Happy Eyeballs in order to 
			report IPv6 failures that force the fall-back to IPv4.</t>
		</abstract>
	</front>

	<middle>
		<section title="Introduction">
			<t>Happy Eyeballs (<xref target="RFC6555"/>) provides a way for improving 
			user-visible delay when IPv6 connectivity is performing worst than the IPv4 
			one.</t>

			<t>However, this hides the possible IPv6 connectivity issues to the operator 
			because users don't notice anything broken, so they aren't reporting it to 
			their providers.</t>

			<t>The goal of this document is to specify an extension of HE, in order to 
			use existing protocols for providing a reporting to the operator, which can 
			be used to setup alarms and trigger further investigation so to improve.</t>

		</section>

		<section title="Using Syslog">
			<t>In order to simplify the reporting of the HE failures, syslog 
			(<xref target="RFC5424"/>) over UDP (<xref target="RFC5426"/>), MUST be 
			used, by means of the default port (514) with IPv6-only.</t>

			<t>The intend is to make this reporting very simple, so no choice of 
			alternative ports or transport protocols is offered.</t>

			<t>Operators willing to use this reporting MUST configure at least one 
			syslog collector at the IPv6 prefix formed as:</t>
			
			<t>Network-Specific Prefix::192.88.99.1</t>
			
			<t>The Network-Specific Prefix (NSP) MUST be chosen by the operator from 
			its RIR allocated IPv6 addressing space.</t>
			
			<t>Additional collectors can be made available by using anycast 
			at the NSP + 192.88.99.0/24 prefix</t>

		</section>

		<section title="Discovery of the syslog collector NSP">
			<t>The same mechanism described by RFC7050 (<xref target="RFC7050"/>) 
			should be used to define the address of the syslog collector(s).</t>

			<t>Because the collectors will be using an IPv6 address with the 32 low 
			order bits from the reserved range 192.88.99.0/24, this will not be in 
			conflict with any public addresses used in Internet, so this mechanism 
			is compatible with the expected usage of the NSP for NAT64.</t>

		</section>

		<section title="HE behaviour on failure detection">
			<t>This section will specify the exact behaviour of HE in order to initiate 
			the reporting and the specific format/parameters of the HE failure 
			message to be sent to the syslog collector.</t>

			<t>A preliminary consideration is to include, in addition to the syslog 
			required parameters, the timeouts detected, the failed destination address 
			and the source prefix from where the destination has failed.</t>
			
			<t>TBD.</t>

		</section>

		<section title="Privacy Considerations">
			<t>The goal is to provide the operator information about the failures 
			detected by HE, without requiring specific users traffic information. 
			Towards this, it will be sufficient to provide to the syslog collector 
			details about the failed destination address and source prefix. So 
			privacy issues regarding identification of a specific device or user are
			avoided.</t>

			<t>TBD.</t>

		</section>


		<section title="Security Considerations">
			<t>This document does not have any specific security considerations.</t>
		</section>

		<section title="IANA Considerations">
			<t>IANA is requested to reserve 192.88.99.0/24, which was previously 
			released by (<xref target="RFC7526"/>) for this RFC.</t>
		</section>

		<section title="Acknowledgements">
			<t>The author would like to acknowledge the inputs of TBD ...</t>
		</section>
	</middle>

  <back>

    <references title="Normative References">
    <?rfc include="reference.RFC.5424" ?>
    <?rfc include="reference.RFC.5426" ?>
    <?rfc include="reference.RFC.6555" ?>
    <?rfc include="reference.RFC.7050" ?>
    <?rfc include="reference.RFC.7526" ?>
    </references>
  </back>

</rfc>
