<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IRTF" category="info" consensus="true" docName="draft-irtf-pearg-numeric-ids-history-11" number="9414" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2023-07-21T16:47:52" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-pearg-numeric-ids-history-11" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9414" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Predictable Transient Numeric IDs">Unfortunate History of Transient Numeric Identifiers</title>
    <seriesInfo name="RFC" value="9414" stream="IRTF"/>
    <author fullname="Fernando Gont" initials="F." surname="Gont">
      <organization abbrev="SI6 Networks" showOnFrontPage="true">SI6 Networks</organization>
      <address>
        <postal>
          <extaddr>Segurola y Habana</extaddr>
          <street>4310 7mo piso</street>
          <city>Ciudad Autonoma de Buenos Aires</city>
          <country>Argentina</country>
        </postal>
        <email>fgont@si6networks.com</email>
        <uri>https://www.si6networks.com</uri>
      </address>
    </author>
    <author fullname="Ivan Arce" initials="I." surname="Arce">
      <organization abbrev="Quarkslab" showOnFrontPage="true">Quarkslab</organization>
      <address>
        <postal>
          <extaddr>Segurola y Habana</extaddr>
          <street>4310 7mo piso</street>
          <city>Ciudad Autonoma de Buenos Aires</city>
          <country>Argentina</country>
        </postal>
        <email>iarce@quarkslab.com</email>
        <uri>https://www.quarkslab.com</uri>
      </address>
    </author>
    <date month="07" year="2023"/>
    <workgroup>Privacy Enhancements and Assessments</workgroup>
    <keyword>security</keyword>
    <keyword>vulnerability</keyword>
    <keyword>algorithm</keyword>
    <keyword>attack</keyword>
    <keyword>fingerprinting</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancements and Assessments Research Group (PEARG) in the IRTF.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Research Task Force
            (IRTF).  The IRTF publishes the results of Internet-related
            research and development activities.  These results might not be
            suitable for deployment.  This RFC represents the consensus of the Privacy Enhancements and Assessments
            Research Group of the Internet Research Task Force (IRTF).
            Documents approved for publication by the IRSG are not
            candidates for any level of Internet Standard; see Section 2 of RFC
            7841.   
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9414" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-threat-model">Threat Model</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issues-with-the-specificati">Issues with the Specification of Transient Numeric Identifiers</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipv4-ipv6-identification">IPv4/IPv6 Identification</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tcp-initial-sequence-number">TCP Initial Sequence Numbers (ISNs)</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipv6-interface-identifiers-">IPv6 Interface Identifiers (IIDs)</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ntp-reference-ids-refids">NTP Reference IDs (REFIDs)</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-protocol-ephemera">Transport-Protocol Ephemeral Port Numbers</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dns-id">DNS ID</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conclusions">Conclusions</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
Networking protocols employ a variety of transient numeric identifiers for different protocol objects, such as IPv4 and IPv6 Identification values <xref target="RFC0791" format="default" sectionFormat="of" derivedContent="RFC0791"/> <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>, IPv6 Interface Identifiers (IIDs) <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/>, transport-protocol ephemeral port numbers <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>, TCP Initial Sequence Numbers (ISNs) <xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/>, NTP Reference IDs (REFIDs) <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905"/>, and DNS IDs <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>. These identifiers typically have specific requirements (e.g., uniqueness during a specified period of time) that must be satisfied such that they do not result in negative interoperability implications and an associated failure severity when such requirements are not met <xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/>.</t>
      <aside pn="section-1-2">
        <t indent="0" pn="section-1-2.1">NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".</t>
      </aside>
      <t indent="0" pn="section-1-3">For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection to information leakages that could be exploited for pervasive monitoring <xref target="RFC7258" format="default" sectionFormat="of" derivedContent="RFC7258"/>. The root cause of these issues has been, in many cases, the poor selection of transient numeric identifiers in such protocols, usually as a result of insufficient or misleading specifications. While it is generally trivial to identify an algorithm that can satisfy the interoperability requirements of a given transient numeric identifier, empirical evidence exists that doing so without negatively affecting the security and/or privacy properties of the aforementioned protocols is prone to error.</t>
      <t indent="0" pn="section-1-4">For example, implementations have been subject to security and/or privacy issues resulting from:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-5">
        <li pn="section-1-5.1">predictable IPv4 or IPv6 Identification values (e.g., see <xref target="Sanfilippo1998a" format="default" sectionFormat="of" derivedContent="Sanfilippo1998a"/>, <xref target="RFC6274" format="default" sectionFormat="of" derivedContent="RFC6274"/>, and <xref target="RFC7739" format="default" sectionFormat="of" derivedContent="RFC7739"/>),</li>
        <li pn="section-1-5.2">predictable IPv6 IIDs (e.g., see <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/>, <xref target="RFC7707" format="default" sectionFormat="of" derivedContent="RFC7707"/>, and <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/>),</li>
        <li pn="section-1-5.3">predictable transport-protocol ephemeral port numbers (e.g., see <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/> and <xref target="Silbersack2005" format="default" sectionFormat="of" derivedContent="Silbersack2005"/>),</li>
        <li pn="section-1-5.4">predictable TCP Initial Sequence Numbers (ISNs) (e.g., see <xref target="Morris1985" format="default" sectionFormat="of" derivedContent="Morris1985"/>, <xref target="Bellovin1989" format="default" sectionFormat="of" derivedContent="Bellovin1989"/>, and <xref target="RFC6528" format="default" sectionFormat="of" derivedContent="RFC6528"/>),</li>
        <li pn="section-1-5.5">predictable initial timestamps in TCP timestamps options (e.g., see <xref target="TCPT-uptime" format="default" sectionFormat="of" derivedContent="TCPT-uptime"/> and <xref target="RFC7323" format="default" sectionFormat="of" derivedContent="RFC7323"/>), and</li>
        <li pn="section-1-5.6">predictable DNS IDs (see, e.g., <xref target="Schuba1993" format="default" sectionFormat="of" derivedContent="Schuba1993"/> and <xref target="Klein2007" format="default" sectionFormat="of" derivedContent="Klein2007"/>).</li>
      </ul>
      <t indent="0" pn="section-1-6">Recent history indicates that, when new protocols are standardized or new protocol implementations are produced, the security and privacy properties of the associated transient numeric identifiers tend to be overlooked, and inappropriate algorithms to generate such identifiers are either suggested in the specifications or selected by implementers. As a result, advice in this area is warranted.
</t>
      <t indent="0" pn="section-1-7">This document contains a non-exhaustive timeline of the specification and vulnerability disclosures related to some sample transient numeric identifiers, including other work that has led to advances in this area. This analysis indicates that:
</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-8">
        <li pn="section-1-8.1">vulnerabilities associated with the inappropriate generation of transient numeric identifiers have affected protocol implementations for an extremely long period of time,</li>
        <li pn="section-1-8.2">such vulnerabilities, even when addressed for a given protocol version, were later reintroduced in new versions or new implementations of the same protocol, and</li>
        <li pn="section-1-8.3">standardization efforts that discuss and provide advice in this area can have a positive effect on IETF specifications and their corresponding implementations.</li>
      </ul>
      <t indent="0" pn="section-1-9">While it is generally possible to identify an algorithm that can satisfy the interoperability requirements for a given transient numeric identifier, this document provides empirical evidence that doing so without negatively affecting the security and/or privacy properties of the corresponding protocols is nontrivial. Other related documents (<xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/> and <xref target="RFC9416" format="default" sectionFormat="of" derivedContent="RFC9416"/>) provide guidance in this area, as motivated by the present document.</t>
      <t indent="0" pn="section-1-10">This document represents the consensus of the Privacy Enhancements and Assessments Research Group (PEARG).</t>
    </section>
    <section anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <dl newline="true" spacing="normal" indent="3" pn="section-2-1">
        <dt pn="section-2-1.1">Transient Numeric Identifier:</dt>
        <dd pn="section-2-1.2">A data object in a protocol specification that can be used to definitely distinguish a protocol object (a datagram, network interface, transport-protocol endpoint, session, etc.) from all other objects of the same type, in a given context. Transient numeric identifiers are usually defined as a series of bits and represented using integer values. These identifiers are typically dynamically selected, as opposed to statically assigned numeric identifiers (e.g., see <xref target="IANA-PROT" format="default" sectionFormat="of" derivedContent="IANA-PROT"/>). We note that different transient numeric identifiers may have additional requirements or properties depending on their specific use in a protocol. We use the term "transient numeric identifier" (or simply "numeric identifier" or "identifier" as short forms) as a generic term to refer to any data object in a protocol specification that satisfies the identification property stated above.
</dd>
      </dl>
      <t indent="0" pn="section-2-2">
   The terms "constant IID", "stable IID", and "temporary IID" are to be
   interpreted as defined in <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/>.

</t>
    </section>
    <section anchor="threat-model" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-threat-model">Threat Model</name>
      <t indent="0" pn="section-3-1">Throughout this document, we do not consider on-path attacks. That is, we assume the attacker does not have physical or logical access to the system(s) being attacked and that the attacker can only observe traffic explicitly directed to the attacker. Similarly, an attacker cannot observe traffic transferred between the sender and the receiver(s) of a target protocol but may be able to interact with any of these entities, including by, e.g., sending any traffic to them to sample transient numeric identifiers employed by the target hosts when communicating with the attacker.
</t>
      <t indent="0" pn="section-3-2">For example, when analyzing vulnerabilities associated with TCP Initial Sequence Numbers (ISNs), we consider the attacker is unable to capture network traffic corresponding to a TCP connection between two other hosts. However, we consider the attacker is able to communicate with any of these hosts (e.g., establish a TCP connection with any of them) to, e.g., sample the TCP ISNs employed by these hosts when communicating with the attacker.</t>
      <t indent="0" pn="section-3-3">Similarly, when considering host-tracking attacks based on IPv6 Interface Identifiers, we consider an attacker may learn the IPv6 address employed by a victim host if, e.g., the address becomes exposed as a result of the victim host communicating with an attacker-operated server. Subsequently, an attacker may perform host-tracking by probing a set of target addresses composed by a set of target prefixes and the IPv6 Interface Identifier originally learned by the attacker.
      Alternatively, an attacker may perform host-tracking if, e.g., the victim host communicates with an attacker-operated server as it moves from one location to another, thereby exposing its configured addresses. We note that none of these scenarios require the attacker observe traffic not explicitly directed to the attacker.
</t>
    </section>
    <section anchor="issues" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-issues-with-the-specificati">Issues with the Specification of Transient Numeric Identifiers</name>
      <t indent="0" pn="section-4-1">While assessing IETF protocol specifications regarding the use of transient numeric identifiers, we have found that most of the issues discussed in this document arise as a result of one of the following conditions:

</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2">
        <li pn="section-4-2.1">protocol specifications that under specify their transient numeric identifiers</li>
        <li pn="section-4-2.2">protocol specifications that over specify their transient numeric identifiers</li>
        <li pn="section-4-2.3">protocol implementations that simply fail to comply with the specified requirements</li>
      </ul>
      <t indent="0" pn="section-4-3">A number of IETF protocol specifications under specified their transient numeric identifiers, thus leading to implementations that were vulnerable to numerous off-path
   attacks. Examples of them are the specification of TCP local ports in <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> or the specification of the DNS ID in <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>.</t>
      <aside pn="section-4-4">
        <t indent="0" pn="section-4-4.1">NOTE: The TCP local port in an active OPEN request is commonly known as the "ephemeral port" of the corresponding TCP connection <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>.</t>
      </aside>
      <t indent="0" pn="section-4-5">On the other hand, there are a number of IETF protocol specifications that over specify some of their associated transient numeric identifiers. For example, <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/> essentially overloads the semantics of IPv6 Interface Identifiers (IIDs) by embedding link-layer addresses in the IPv6 IIDs when the interoperability requirement of uniqueness could be achieved in other ways that do not result in negative security and privacy implications <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/>. Similarly, <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> suggests the use of a global counter for the generation of Identification values when the interoperability requirement of uniqueness per {IPv6 Source Address, IPv6 Destination Address} could be achieved with other algorithms that do not result in negative security and privacy implications <xref target="RFC7739" format="default" sectionFormat="of" derivedContent="RFC7739"/>.</t>
      <t indent="0" pn="section-4-6">Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. For example, some popular operating systems still fail to implement transport-protocol ephemeral port randomization, as recommended in <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>, or TCP Initial Sequence Number randomization, as recommended in <xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/>.</t>
      <t indent="0" pn="section-4-7">The following subsections document the timelines for a number of sample transient numeric identifiers that illustrate how the problem discussed in this document has affected protocols from different layers over time. These sample transient numeric identifiers have different interoperability requirements and failure severities (see <xref target="RFC9415" section="6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9415#section-6" derivedContent="RFC9415"/>), and thus are considered to be representative of the problem being analyzed in this document.</t>
      <section anchor="ipid" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-ipv4-ipv6-identification">IPv4/IPv6 Identification</name>
        <t indent="0" pn="section-4.1-1">This section presents the timeline of the Identification field employed by IPv4 (in the base header) and IPv6 (in Fragment Headers). The reason for presenting both cases in the same section is to make it evident that, while the Identification value serves the same purpose in both protocols, the work and research done for the IPv4 case did not influence IPv6 specifications or implementations.</t>
        <t indent="0" pn="section-4.1-2">The IPv4 Identification is specified in <xref target="RFC0791" format="default" sectionFormat="of" derivedContent="RFC0791"/>, which specifies the interoperability requirements for the Identification field, i.e., the sender must choose the Identification field to be unique for a given {Source Address, Destination Address, Protocol} for the time the datagram (or any fragment of it) could be alive in the Internet.  It suggests that a sending protocol module may keep "a table of Identifiers, one entry for each destination it has communicated with in the last maximum packet lifetime for the [I]nternet", and it also suggests that "since the Identifier field allows 65,536 different values, hosts may be able to simply use unique identifiers independent of destination". The above has been interpreted numerous times as a suggestion to employ per-destination or global counters for the generation of Identification values. While <xref target="RFC0791" format="default" sectionFormat="of" derivedContent="RFC0791"/> does not suggest any flawed algorithm for the generation of Identification values, the specification omits a discussion of the security and privacy implications of predictable Identification values. This resulted in many IPv4 implementations generating predictable Identification values by means of a global counter, at least at some point in time.
</t>
        <t indent="0" pn="section-4.1-3">
The IPv6 Identification was originally specified in <xref target="RFC1883" format="default" sectionFormat="of" derivedContent="RFC1883"/>. It serves the same purpose as its IPv4 counterpart, but rather than being part of the base header (as in the IPv4 case), it is part of the Fragment Header (which may or may not be present in an IPv6 packet). <xref target="RFC1883" format="default" sectionFormat="of" section="4.5" derivedLink="https://rfc-editor.org/rfc/rfc1883#section-4.5" derivedContent="RFC1883"/> states that the Identification must be different than that of any other fragmented packet sent recently (within the maximum likely lifetime of a packet) with the same Source Address and Destination Address. Subsequently, it notes that this requirement can be met by means of a wrap-around 32-bit counter that is incremented each time a packet must be fragmented and that it is an implementation choice whether to use a global or a per-destination counter. Thus, the specification of the IPv6 Identification is similar to that of the IPv4 case, with the only difference that, in the IPv6 case, the suggestions to use simple counters is more explicit. <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> is the first revision of the core IPv6 specification and maintains the same text for the specification of the IPv6 Identification field. <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>, the second revision of the core IPv6 specification, removes the suggestion from <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> to use a counter for the generation of IPv6 Identification values and points to <xref target="RFC7739" format="default" sectionFormat="of" derivedContent="RFC7739"/> for sample algorithms for their generation.
</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.1-4">
          <dt pn="section-4.1-4.1">September 1981:</dt>
          <dd pn="section-4.1-4.2">
            <xref target="RFC0791" format="default" sectionFormat="of" derivedContent="RFC0791"/> specifies the interoperability requirements for the IPv4 Identification but does not perform a vulnerability assessment of this transient numeric identifier.
</dd>
          <dt pn="section-4.1-4.3">December 1995:</dt>
          <dd pn="section-4.1-4.4">
            <xref target="RFC1883" format="default" sectionFormat="of" derivedContent="RFC1883"/>, the first specification of the IPv6 protocol, is published. It suggests that a counter be used to generate the IPv6 Identification values and notes that it is an implementation choice whether to maintain a single counter for the node or multiple counters (e.g., one for each of the node's possible Source Addresses, or one for each active {Source Address, Destination Address} set).
</dd>
          <dt pn="section-4.1-4.5">December 1998:</dt>
          <dd pn="section-4.1-4.6">
            <xref target="Sanfilippo1998a" format="default" sectionFormat="of" derivedContent="Sanfilippo1998a"/> finds that predictable IPv4 Identification values (as generated by most popular implementations) can be leveraged to count the number of packets sent by a target node. <xref target="Sanfilippo1998b" format="default" sectionFormat="of" derivedContent="Sanfilippo1998b"/> explains how to leverage the same vulnerability to implement a port-scanning technique known as "idle scan". A tool that implements this attack is publicly released.
</dd>
          <dt pn="section-4.1-4.7">December 1998:</dt>
          <dd pn="section-4.1-4.8">
            <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/>, a revision of the IPv6 specification, is published, obsoleting <xref target="RFC1883" format="default" sectionFormat="of" derivedContent="RFC1883"/>. It maintains the same specification of the IPv6 Identification field as its predecessor <xref target="RFC1883" format="default" sectionFormat="of" derivedContent="RFC1883"/>.
</dd>
          <dt pn="section-4.1-4.9">December 1998:</dt>
          <dd pn="section-4.1-4.10">OpenBSD implements randomization of the IPv4 Identification field <xref target="OpenBSD-IPv4-ID" format="default" sectionFormat="of" derivedContent="OpenBSD-IPv4-ID"/>.
</dd>
          <dt pn="section-4.1-4.11">November 1999:</dt>
          <dd pn="section-4.1-4.12">
            <xref target="Sanfilippo1999" format="default" sectionFormat="of" derivedContent="Sanfilippo1999"/> discusses how to leverage predictable IPv4 Identification values to uncover the rules of a number of firewalls.
</dd>
          <dt pn="section-4.1-4.13">September 2002:</dt>
          <dd pn="section-4.1-4.14">
            <xref target="Fyodor2002" format="default" sectionFormat="of" derivedContent="Fyodor2002"/> documents the implementation of the "idle scan" technique in the popular Network Mapper (nmap) tool.
</dd>
          <dt pn="section-4.1-4.15">November 2002:</dt>
          <dd pn="section-4.1-4.16">
            <xref target="Bellovin2002" format="default" sectionFormat="of" derivedContent="Bellovin2002"/> explains how the IPv4 Identification field can be exploited to count the number of systems behind a NAT.
</dd>
          <dt pn="section-4.1-4.17">October 2003:</dt>
          <dd pn="section-4.1-4.18">OpenBSD implements randomization of the IPv6 Identification field <xref target="OpenBSD-IPv6-ID" format="default" sectionFormat="of" derivedContent="OpenBSD-IPv6-ID"/>.
</dd>
          <dt pn="section-4.1-4.19">December 2003:</dt>
          <dd pn="section-4.1-4.20">
            <xref target="Zalewski2003" format="default" sectionFormat="of" derivedContent="Zalewski2003"/> explains a technique to perform TCP data injection attacks based on predictable IPv4 Identification values, which requires less effort than TCP injection attacks performed with bare TCP packets.
</dd>
          <dt pn="section-4.1-4.21">January 2005:</dt>
          <dd pn="section-4.1-4.22">
            <xref target="Silbersack2005" format="default" sectionFormat="of" derivedContent="Silbersack2005"/> discusses shortcomings in a number of techniques to mitigate predictable IPv4 Identification values.
</dd>
          <dt pn="section-4.1-4.23">October 2007:</dt>
          <dd pn="section-4.1-4.24">
            <xref target="Klein2007" format="default" sectionFormat="of" derivedContent="Klein2007"/> describes a weakness in the pseudorandom number generator (PRNG) in use for the generation of IP Identification values by a number of operating systems.
</dd>
          <dt pn="section-4.1-4.25">June 2011:</dt>
          <dd pn="section-4.1-4.26">
            <xref target="Gont2011" format="default" sectionFormat="of" derivedContent="Gont2011"/> describes how to perform idle scan attacks in IPv6.
	  </dd>
          <dt pn="section-4.1-4.27">November 2011:</dt>
          <dd pn="section-4.1-4.28">Linux mitigates predictable IPv6 Identification values <xref target="RedHat2011" format="default" sectionFormat="of" derivedContent="RedHat2011"/> <xref target="SUSE2011" format="default" sectionFormat="of" derivedContent="SUSE2011"/> <xref target="Ubuntu2011" format="default" sectionFormat="of" derivedContent="Ubuntu2011"/>.
</dd>
          <dt pn="section-4.1-4.29">December 2011:</dt>
          <dd pn="section-4.1-4.30">
            <xref target="draft-gont-6man-predictable-fragment-id-00" format="default" sectionFormat="of" derivedContent="draft-gont-6man-predictable-fragment-id-00"/> describes the security implications of predictable IPv6 Identification values and possible mitigations. This document has the intended status of "Standards Track", with the intention to formally update <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> to introduce security and privacy requirements on the generation of IPv6 Identification values.
</dd>
          <dt pn="section-4.1-4.31">May 2012:</dt>
          <dd pn="section-4.1-4.32">
            <xref target="Gont2012" format="default" sectionFormat="of" derivedContent="Gont2012"/> notes that some major IPv6 implementations still employ predictable IPv6 Identification values.
</dd>
          <dt pn="section-4.1-4.33">March 2013:</dt>
          <dd pn="section-4.1-4.34">The 6man WG adopts <xref target="draft-gont-6man-predictable-fragment-id-03" format="default" sectionFormat="of" derivedContent="draft-gont-6man-predictable-fragment-id-03"/> but changes the track to "BCP" (while still formally updating <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/>), posting the resulting document as <xref target="draft-ietf-6man-predictable-fragment-id-00" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-predictable-fragment-id-00"/>.
</dd>
          <dt pn="section-4.1-4.35">June 2013:</dt>
          <dd pn="section-4.1-4.36">A patch to incorporate support for IPv6-based idle scans in nmap is submitted <xref target="Morbitzer2013" format="default" sectionFormat="of" derivedContent="Morbitzer2013"/>.
</dd>
          <dt pn="section-4.1-4.37">December 2014:</dt>
          <dd pn="section-4.1-4.38">The 6man WG changes the intended status of <xref target="draft-ietf-6man-predictable-fragment-id-01" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-predictable-fragment-id-01"/> to "Informational" and posts it as <xref target="draft-ietf-6man-predictable-fragment-id-02" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-predictable-fragment-id-02"/>. As a result, it no longer formally updates <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/>, and security and privacy requirements on the generation of IPv6 Identification values are eliminated.
</dd>
          <dt pn="section-4.1-4.39">June 2015:</dt>
          <dd pn="section-4.1-4.40">
            <xref target="draft-ietf-6man-predictable-fragment-id-08" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-predictable-fragment-id-08"/> notes that some popular host and router implementations still employ predictable IPv6 Identification values.
</dd>
          <dt pn="section-4.1-4.41">February 2016:</dt>
          <dd pn="section-4.1-4.42">
            <xref target="RFC7739" format="default" sectionFormat="of" derivedContent="RFC7739"/> (based on <xref target="draft-ietf-6man-predictable-fragment-id-10" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-predictable-fragment-id-10"/>) analyzes the security and privacy implications of predictable IPv6 Identification values and provides guidance for selecting an algorithm to generate such values. However, being published as an "Informational" RFC, it does not formally update <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> and does not introduce security and privacy requirements on the generation of IPv6 Identification values. 
	  </dd>
          <dt pn="section-4.1-4.43">June 2016:</dt>
          <dd pn="section-4.1-4.44">
            <xref target="draft-ietf-6man-rfc2460bis-05" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-rfc2460bis-05"/>, a draft revision of <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/>, removes the suggestion from <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> to use a counter for the generation of IPv6 Identification values but does not perform a vulnerability assessment of the generation of IPv6 Identification values and does not introduce security and privacy requirements on the generation of IPv6 Identification values.
</dd>
          <dt pn="section-4.1-4.45">July 2017:</dt>
          <dd pn="section-4.1-4.46">
            <xref target="draft-ietf-6man-rfc2460bis-13" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-rfc2460bis-13"/> is finally published as <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>, obsoleting <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> and pointing to <xref target="RFC7739" format="default" sectionFormat="of" derivedContent="RFC7739"/> for sample algorithms for the generation of IPv6 Identification values. However, it does not introduce security and privacy requirements on the generation of IPv6 Identification values.
</dd>
          <dt pn="section-4.1-4.47">October 2019:</dt>
          <dd pn="section-4.1-4.48">
            <xref target="IPID-DEV" format="default" sectionFormat="of" derivedContent="IPID-DEV"/> notes that the IPv6 Identification generators of two popular operating systems are flawed.
</dd>
        </dl>
      </section>
      <section anchor="tcp-isns" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-tcp-initial-sequence-number">TCP Initial Sequence Numbers (ISNs)</name>
        <t indent="0" pn="section-4.2-1">
<xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> suggests that the choice of the ISN of a connection is not arbitrary but aims to reduce the chances of a stale segment from being accepted by a new incarnation of a previous connection. <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> suggests the use of a global 32-bit ISN generator that is incremented by 1 roughly every 4 microseconds. However, as a matter of fact, protection against stale segments from a previous incarnation of the connection is enforced by preventing the creation of a new incarnation of a previous connection before 2*MSL has passed since a segment corresponding to the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/>). This is accomplished by the TIME-WAIT state and TCP's "quiet time" concept (see <xref target="RFC1323" format="default" sectionFormat="of" section="B" derivedLink="https://rfc-editor.org/rfc/rfc1323#appendix-B" derivedContent="RFC1323"/>). Based on the assumption that ISNs are monotonically increasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an incoming SYN segment to perform "heuristics" that enable the creation of a new incarnation of a connection while the previous incarnation is still in the TIME-WAIT state (see p. 945 of <xref target="Wright1994" format="default" sectionFormat="of" derivedContent="Wright1994"/>). This avoids an interoperability problem that may arise when a node establishes connections to a specific TCP end-point at a high rate <xref target="Silbersack2005" format="default" sectionFormat="of" derivedContent="Silbersack2005"/>.</t>
        <t indent="0" pn="section-4.2-2">The interoperability requirements for TCP ISNs are probably not as clearly spelled out as one would expect. Furthermore, the suggestion of employing a global counter in <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> negatively affects the security and privacy properties of the protocol.</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.2-3">
          <dt pn="section-4.2-3.1">September 1981:</dt>
          <dd pn="section-4.2-3.2">
            <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> suggests the use of a global 32-bit ISN
generator, whose lower bit is incremented roughly every 4 microseconds. However, such an ISN generator makes it trivial to predict the ISN that a TCP implementation will use for new connections, thus allowing a variety of attacks against TCP.
</dd>
          <dt pn="section-4.2-3.3">February 1985:</dt>
          <dd pn="section-4.2-3.4">
            <xref target="Morris1985" format="default" sectionFormat="of" derivedContent="Morris1985"/> is the first to describe how to exploit predictable TCP ISNs for forging TCP connections that could then be leveraged for trust relationship exploitation.
</dd>
          <dt pn="section-4.2-3.5">April 1989:</dt>
          <dd pn="section-4.2-3.6">
            <xref target="Bellovin1989" format="default" sectionFormat="of" derivedContent="Bellovin1989"/> discusses the security considerations for predictable ISNs (along with a range of other protocol-based vulnerabilities).
</dd>
          <dt pn="section-4.2-3.7">January 1995:</dt>
          <dd pn="section-4.2-3.8">
            <xref target="Shimomura1995" format="default" sectionFormat="of" derivedContent="Shimomura1995"/> reports a real-world exploitation of the vulnerability described in <xref target="Morris1985" format="default" sectionFormat="of" derivedContent="Morris1985"/> ten years before (in 1985).
</dd>
          <dt pn="section-4.2-3.9">May 1996:</dt>
          <dd pn="section-4.2-3.10">
            <xref target="RFC1948" format="default" sectionFormat="of" derivedContent="RFC1948"/> is the first IETF effort, authored by Steven Bellovin, to address predictable TCP ISNs. However, <xref target="RFC1948" format="default" sectionFormat="of" derivedContent="RFC1948"/> does not formally update <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/>. Note: The same concept specified in this document for TCP ISNs was later proposed for TCP ephemeral ports <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>, TCP Timestamps, and eventually even IPv6 Interface Identifiers <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/>.
</dd>
          <dt pn="section-4.2-3.11">July 1996:</dt>
          <dd pn="section-4.2-3.12">OpenBSD implements TCP ISN randomization based on random increments (please see <xref target="RFC9415" format="default" sectionFormat="of" section="A.2" derivedLink="https://rfc-editor.org/rfc/rfc9415#appendix-A.2" derivedContent="RFC9415"/>) <xref target="OpenBSD-TCP-ISN-I" format="default" sectionFormat="of" derivedContent="OpenBSD-TCP-ISN-I"/>.
</dd>
          <dt pn="section-4.2-3.13">December 2000:</dt>
          <dd pn="section-4.2-3.14">OpenBSD implements TCP ISN randomization using simple randomization (please see <xref target="RFC9415" section="7.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9415#section-7.1" derivedContent="RFC9415"/>)  <xref target="OpenBSD-TCP-ISN-R" format="default" sectionFormat="of" derivedContent="OpenBSD-TCP-ISN-R"/>.
</dd>
          <dt pn="section-4.2-3.15">March 2001:</dt>
          <dd pn="section-4.2-3.16">
            <xref target="Zalewski2001" format="default" sectionFormat="of" derivedContent="Zalewski2001"/> provides a detailed analysis of statistical weaknesses in some TCP ISN generators and includes a survey of the algorithms in use by popular TCP implementations. Vulnerability advisories <xref target="USCERT2001" format="default" sectionFormat="of" derivedContent="USCERT2001"/> were released regarding statistical weaknesses in some TCP ISN generators, affecting popular TCP implementations. Other vulnerability advisories on the same vulnerability, such as <xref target="CERT2001" format="default" sectionFormat="of" derivedContent="CERT2001"/>, were published later on.</dd>
          <dt pn="section-4.2-3.17">March 2002:</dt>
          <dd pn="section-4.2-3.18">
            <t indent="0" pn="section-4.2-3.18.1"><xref target="Zalewski2002" format="default" sectionFormat="of" derivedContent="Zalewski2002"/> updates and complements <xref target="Zalewski2001" format="default" sectionFormat="of" derivedContent="Zalewski2001"/>. It concludes that "while some vendors [...] reacted promptly and tested their solutions properly, many still either ignored the issue and never evaluated their implementations, or implemented a flawed solution that apparently was not tested using a known approach" <xref target="Zalewski2002" format="default" sectionFormat="of" derivedContent="Zalewski2002"/>.</t>
          </dd>
          <dt pn="section-4.2-3.19">June 2007:</dt>
          <dd pn="section-4.2-3.20">OpenBSD implements TCP ISN randomization based on the algorithm specified in <xref target="RFC1948" format="default" sectionFormat="of" derivedContent="RFC1948"/> (currently obsoleted and replaced by <xref target="RFC6528" format="default" sectionFormat="of" derivedContent="RFC6528"/>) for the TCP endpoint that performs the active open while keeping the simple randomization scheme for the endpoint performing the passive open <xref target="OpenBSD-TCP-ISN-H" format="default" sectionFormat="of" derivedContent="OpenBSD-TCP-ISN-H"/>. This provides monotonically increasing ISNs for the "client side" (allowing the BSD heuristics to work as expected) while avoiding any patterns in the ISN generation for the "server side".
</dd>
          <dt pn="section-4.2-3.21">February 2012:</dt>
          <dd pn="section-4.2-3.22">
            <xref target="RFC6528" format="default" sectionFormat="of" derivedContent="RFC6528"/>, published 27 years after Morris's original work <xref target="Morris1985" format="default" sectionFormat="of" derivedContent="Morris1985"/>, formally updates <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> to mitigate predictable TCP ISNs. 
	  </dd>
          <dt pn="section-4.2-3.23">August 2014:</dt>
          <dd pn="section-4.2-3.24">
            The algorithm specified in <xref target="RFC6528" format="default" sectionFormat="of" derivedContent="RFC6528"/> becomes the recommended ("<bcp14>SHOULD</bcp14>") algorithm for TCP ISN generation in <xref target="draft-eddy-rfc793bis-04" format="default" sectionFormat="of" derivedContent="draft-eddy-rfc793bis-04"/>, an early revision of the core TCP specification <xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/>. 
</dd>
          <dt pn="section-4.2-3.25">August 2022:</dt>
          <dd pn="section-4.2-3.26">
            <xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/>, a revision of the core TCP specification, is published, adopting the algorithm specified in <xref target="RFC6528" format="default" sectionFormat="of" derivedContent="RFC6528"/> as the recommended ("<bcp14>SHOULD</bcp14>") algorithm for TCP ISN generation. 
</dd>
        </dl>
      </section>
      <section anchor="ipv6-iids" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-ipv6-interface-identifiers-">IPv6 Interface Identifiers (IIDs)</name>
        <t indent="0" pn="section-4.3-1">IPv6 Interface Identifiers can be generated as a result of different mechanisms, including Stateless Address Autoconfiguration (SLAAC) <xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/>, DHCPv6 <xref target="RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/>, and manual configuration. This section focuses on Interface Identifiers resulting from SLAAC.</t>
        <t indent="0" pn="section-4.3-2">The Interface Identifier of stable IPv6 addresses resulting from SLAAC originally resulted in the underlying link-layer address being embedded in the IID. At the time, employing the underlying link-layer address for the IID was seen as a convenient way to obtain a unique address. However, recent awareness about the security and privacy properties of this approach <xref target="RFC7707" format="default" sectionFormat="of" derivedContent="RFC7707"/> <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/> has led to the replacement of this flawed scheme with an alternative one <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/> <xref target="RFC8064" format="default" sectionFormat="of" derivedContent="RFC8064"/> that does not negatively affect the security and privacy properties of the protocol.
</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.3-3">
          <dt pn="section-4.3-3.1">January 1997:</dt>
          <dd pn="section-4.3-3.2">
            <xref target="RFC2073" format="default" sectionFormat="of" derivedContent="RFC2073"/> specifies the syntax of IPv6 global addresses (referred to as "An IPv6 Provider-Based Unicast Address Format" at the time), which is consistent with the IPv6 addressing architecture specified in <xref target="RFC1884" format="default" sectionFormat="of" derivedContent="RFC1884"/>.
	    Hosts are recommended to "generate addresses using link-specific addresses as Interface ID such as 48 bit IEEE-802 MAC addresses".
	  </dd>
          <dt pn="section-4.3-3.3">July 1998:</dt>
          <dd pn="section-4.3-3.4">
            <xref target="RFC2374" format="default" sectionFormat="of" derivedContent="RFC2374"/> specifies "An IPv6 Aggregatable Global Unicast Address Format" (obsoleting <xref target="RFC2073" format="default" sectionFormat="of" derivedContent="RFC2073"/>), changing the size of the IID to 64 bits, and specifies that IIDs must be constructed in IEEE 64-bit Extended Unique Identifier (EUI-64) format. How such identifiers are constructed is specified in the corresponding "IPv6 over &lt;link&gt;" specifications, such as "IPv6 over Ethernet".
</dd>
          <dt pn="section-4.3-3.5">January 2001:</dt>
          <dd pn="section-4.3-3.6">
            <xref target="RFC3041" format="default" sectionFormat="of" derivedContent="RFC3041"/> recognizes the problem of IPv6 network activity correlation and specifies IPv6 temporary addresses. Temporary addresses are to be used along with stable addresses.
</dd>
          <dt pn="section-4.3-3.7">August 2003:</dt>
          <dd pn="section-4.3-3.8">
            <xref target="RFC3587" format="default" sectionFormat="of" derivedContent="RFC3587"/> obsoletes <xref target="RFC2374" format="default" sectionFormat="of" derivedContent="RFC2374"/>, making the Top-Level Aggregator  (TLA) / Next-Level
   Aggregator (NLA) structure historic, though the syntax and recommendations for the stable IIDs remain unchanged.
</dd>
          <dt pn="section-4.3-3.9">February 2006:</dt>
          <dd pn="section-4.3-3.10">
            <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/> is published as the latest "IP Version 6 Addressing Architecture", requiring the IIDs of "all unicast addresses, except those that start with the binary value 000" to employ the Modified EUI-64 format. The details of constructing such interface identifiers are defined in the corresponding "IPv6 over &lt;link&gt;" specifications.
</dd>
          <dt pn="section-4.3-3.11">March 2008:</dt>
          <dd pn="section-4.3-3.12">
            <xref target="RFC5157" format="default" sectionFormat="of" derivedContent="RFC5157"/> provides hints regarding how patterns in IPv6 addresses could be leveraged for the purpose of address scanning.
</dd>
          <dt pn="section-4.3-3.13">December 2011:</dt>
          <dd pn="section-4.3-3.14">
            <xref target="draft-gont-6man-stable-privacy-addresses-00" format="default" sectionFormat="of" derivedContent="draft-gont-6man-stable-privacy-addresses-00"/> notes that the original scheme for generating stable addresses allows for IPv6 address scanning and for active host tracking (even when IPv6 temporary addresses are employed). It also specifies an alternative algorithm meant to replace IIDs based on Modified EUI-64 format identifiers.
</dd>
          <dt pn="section-4.3-3.15">November 2012:</dt>
          <dd pn="section-4.3-3.16">The 6man WG adopts <xref target="draft-gont-6man-stable-privacy-addresses-01" format="default" sectionFormat="of" derivedContent="draft-gont-6man-stable-privacy-addresses-01"/> as a working group item (as <xref target="draft-ietf-6man-stable-privacy-addresses-00" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-stable-privacy-addresses-00"/>). However, the document no longer formally updates <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/>; therefore, the specified algorithm no longer formally replaces the Modified EUI-64 format identifiers.
</dd>
          <dt pn="section-4.3-3.17">February 2013:</dt>
          <dd pn="section-4.3-3.18">An address-scanning tool (scan6 of <xref target="IPv6-Toolkit" format="default" sectionFormat="of" derivedContent="IPv6-Toolkit"/>) that leverages IPv6 address patterns is released <xref target="Gont2013" format="default" sectionFormat="of" derivedContent="Gont2013"/>.
</dd>
          <dt pn="section-4.3-3.19">July 2013:</dt>
          <dd pn="section-4.3-3.20">
            <xref target="draft-cooper-6man-ipv6-address-generation-privacy-00" format="default" sectionFormat="of" derivedContent="draft-cooper-6man-ipv6-address-generation-privacy-00"/> elaborates on the security and privacy properties of all known algorithms for generating IPv6 IIDs.
</dd>
          <dt pn="section-4.3-3.21">January 2014:</dt>
          <dd pn="section-4.3-3.22">The 6man WG posts <xref target="draft-ietf-6man-default-iids-00" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-default-iids-00"/> ("Recommendation on Stable IPv6 Interface Identifiers"), recommending <xref target="draft-ietf-6man-stable-privacy-addresses-17" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-stable-privacy-addresses-17"/> for the generation of stable addresses.
</dd>
          <dt pn="section-4.3-3.23">April 2014:</dt>
          <dd pn="section-4.3-3.24">
            <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/> (formerly <xref target="draft-ietf-6man-stable-privacy-addresses-17" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-stable-privacy-addresses-17"/>) is published, specifying "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" as an alternative to (but <strong>not</strong> replacement of) Modified EUI-64 format IIDs.
</dd>
          <dt pn="section-4.3-3.25">March 2016:</dt>
          <dd pn="section-4.3-3.26">
            <xref target="RFC7707" format="default" sectionFormat="of" derivedContent="RFC7707"/> (formerly <xref target="draft-gont-opsec-ipv6-host-scanning-02" format="default" sectionFormat="of" derivedContent="draft-gont-opsec-ipv6-host-scanning-02"/> and later <xref target="draft-ietf-opsec-ipv6-host-scanning-08" format="default" sectionFormat="of" derivedContent="draft-ietf-opsec-ipv6-host-scanning-08"/>), about "Network Reconnaissance in IPv6 Networks", is published.
</dd>
          <dt pn="section-4.3-3.27">March 2016:</dt>
          <dd pn="section-4.3-3.28">
            <xref target="RFC7721" format="default" sectionFormat="of" derivedContent="RFC7721"/> (formerly <xref target="draft-cooper-6man-ipv6-address-generation-privacy-00" format="default" sectionFormat="of" derivedContent="draft-cooper-6man-ipv6-address-generation-privacy-00"/> and later <xref target="draft-ietf-6man-ipv6-address-generation-privacy-08" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-ipv6-address-generation-privacy-08"/>), about "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", is published.
</dd>
          <dt pn="section-4.3-3.29">May 2016:</dt>
          <dd pn="section-4.3-3.30">
            <xref target="draft-gont-6man-non-stable-iids-00" format="default" sectionFormat="of" derivedContent="draft-gont-6man-non-stable-iids-00"/> is posted, with the goal of specifying requirements for non-stable addresses and updating <xref target="RFC4941" format="default" sectionFormat="of" derivedContent="RFC4941"/> such that use of only temporary addresses is allowed.
</dd>
          <dt pn="section-4.3-3.31">May 2016:</dt>
          <dd pn="section-4.3-3.32">
            <xref target="draft-gont-6man-address-usage-recommendations-00" format="default" sectionFormat="of" derivedContent="draft-gont-6man-address-usage-recommendations-00"/> is posted, providing an analysis of how different aspects on an address (from stability to usage mode) affect their corresponding security and privacy properties and meaning to eventually provide advice in this area.
</dd>
          <dt pn="section-4.3-3.33">February 2017:</dt>
          <dd pn="section-4.3-3.34">
            <xref target="draft-ietf-6man-default-iids-16" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-default-iids-16"/>, produced by the 6man WG, is published as <xref target="RFC8064" format="default" sectionFormat="of" derivedContent="RFC8064"/> ("Recommendation on Stable IPv6 Interface Identifiers"), with requirements for stable addresses and a recommendation to employ <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/> for the generation of stable addresses. It formally updates a large number of RFCs.
</dd>
          <dt pn="section-4.3-3.35">March 2018:</dt>
          <dd pn="section-4.3-3.36">
            <xref target="draft-fgont-6man-rfc4941bis-00" format="default" sectionFormat="of" derivedContent="draft-fgont-6man-rfc4941bis-00"/> is posted (as suggested by the 6man WG) to address flaws in <xref target="RFC4941" format="default" sectionFormat="of" derivedContent="RFC4941"/> by revising it (as an alternative to the <xref target="draft-gont-6man-non-stable-iids-00" format="default" sectionFormat="of" derivedContent="draft-gont-6man-non-stable-iids-00"/> effort, posted in March 2016).
</dd>
          <dt pn="section-4.3-3.37">July 2018:</dt>
          <dd pn="section-4.3-3.38">
            <xref target="draft-fgont-6man-rfc4941bis-00" format="default" sectionFormat="of" derivedContent="draft-fgont-6man-rfc4941bis-00"/> is adopted (as <xref target="draft-ietf-6man-rfc4941bis-00" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-rfc4941bis-00"/>) as a WG item of the 6man WG.
</dd>
          <dt pn="section-4.3-3.39">December 2020:</dt>
          <dd pn="section-4.3-3.40">
            <xref target="draft-ietf-6man-rfc4941bis-12" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-rfc4941bis-12"/> is approved by the IESG for publication as an RFC.
</dd>
          <dt pn="section-4.3-3.41">February 2021:</dt>
          <dd pn="section-4.3-3.42">
            <xref target="draft-ietf-6man-rfc4941bis-12" format="default" sectionFormat="of" derivedContent="draft-ietf-6man-rfc4941bis-12"/> is finally published as <xref target="RFC8981" format="default" sectionFormat="of" derivedContent="RFC8981"/>.
</dd>
        </dl>
      </section>
      <section anchor="ntp-refid" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-ntp-reference-ids-refids">NTP Reference IDs (REFIDs)</name>
        <t indent="0" pn="section-4.4-1">The NTP <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905"/> Reference ID is a 32-bit code identifying the particular server or reference clock. Above stratum 1 (secondary servers and clients), this value can be employed to avoid degree-one timing loops, that is, scenarios where two NTP peers are (mutually) the time source of each other. If using the IPv4 address family, the identifier is the four-octet IPv4 address.  If using the IPv6 address family, it is the first four octets of the MD5 hash of the IPv6 address.</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.4-2">
          <dt pn="section-4.4-2.1">June 2010:</dt>
          <dd pn="section-4.4-2.2">
            <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905"/> ("Network Time Protocol Version 4: Protocol and Algorithms Specification") is published. It specifies that, for NTP peers with stratum higher than 1, the REFID embeds the IPv4 address of the time source or the first four octets of the MD5 hash of the IPv6 address of the time source.
</dd>
          <dt pn="section-4.4-2.3">July 2016:</dt>
          <dd pn="section-4.4-2.4">
            <xref target="draft-stenn-ntp-not-you-refid-00" format="default" sectionFormat="of" derivedContent="draft-stenn-ntp-not-you-refid-00"/> is posted, describing the information leakage produced via the NTP REFID. It proposes that NTP returns a special REFID when a packet employs an IP Source Address that is not believed to be a current NTP peer but otherwise generates and returns the common REFID. It is subsequently adopted by the NTP WG as <xref target="draft-ietf-ntp-refid-updates-00" format="default" sectionFormat="of" derivedContent="draft-ietf-ntp-refid-updates-00"/>.
</dd>
          <dt pn="section-4.4-2.5">April 2019:</dt>
          <dd pn="section-4.4-2.6">
            <xref target="Gont-NTP" format="default" sectionFormat="of" derivedContent="Gont-NTP"/> notes that the proposed fix specified in <xref target="draft-ietf-ntp-refid-updates-00" format="default" sectionFormat="of" derivedContent="draft-ietf-ntp-refid-updates-00"/> is, at the very least, sub-optimal. As a result of a lack of WG support, the <xref target="draft-ietf-ntp-refid-updates-00" format="default" sectionFormat="of" derivedContent="draft-ietf-ntp-refid-updates-00"/> effort is eventually abandoned.
</dd>
        </dl>
      </section>
      <section anchor="port-numbers" numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-transport-protocol-ephemera">Transport-Protocol Ephemeral Port Numbers</name>
        <t indent="0" pn="section-4.5-1">Most (if not all) transport protocols employ "port numbers" to demultiplex packets to the corresponding transport-protocol instances. "Ephemeral ports" refer to the local ports employed in active OPEN requests, that is, typically the local port numbers employed on the side initiating the communication.</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.5-2">
          <dt pn="section-4.5-2.1">August 1980:</dt>
          <dd pn="section-4.5-2.2">
            <xref target="RFC0768" format="default" sectionFormat="of" derivedContent="RFC0768"/> notes that the UDP source port is optional and identifies the port of the sending process. It does not specify interoperability requirements for source port selection, nor does it suggest possible ways to select port numbers. Most popular implementations end up selecting source ports from a system-wide global counter.</dd>
          <dt pn="section-4.5-2.3">September 1981:</dt>
          <dd pn="section-4.5-2.4">
            <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/> (the TCP specification) essentially describes the use of port numbers and specifies that port numbers should result in a unique socket pair {local address, local port, remote address, remote port}. How ephemeral ports are selected and the port range from which they are selected are left unspecified.
</dd>
          <dt pn="section-4.5-2.5">July 1996:</dt>
          <dd pn="section-4.5-2.6">OpenBSD implements ephemeral port randomization <xref target="OpenBSD-PR" format="default" sectionFormat="of" derivedContent="OpenBSD-PR"/>.
</dd>
          <dt pn="section-4.5-2.7">July 2008:</dt>
          <dd pn="section-4.5-2.8">The CERT Coordination Center publishes details of what became known as the "Kaminsky Attack" <xref target="VU-800113" format="default" sectionFormat="of" derivedContent="VU-800113"/> <xref target="Kaminsky2008" format="default" sectionFormat="of" derivedContent="Kaminsky2008"/> on the DNS. The attack exploits the lack of ephemeral port randomization and DNS ID randomization in many major DNS implementations to perform cache poisoning in an effective and practical manner.
</dd>
          <dt pn="section-4.5-2.9">January 2009:</dt>
          <dd pn="section-4.5-2.10">
            <xref target="RFC5452" format="default" sectionFormat="of" derivedContent="RFC5452"/> mandates the use of port randomization for DNS resolvers and mandates that implementations must randomize ports from the range of available ports (53 or 1024 and above) that is as large as possible and practicable. It does not recommend possible algorithms for port randomization, although the document specifically targets DNS resolvers, for which a simple port randomization suffices (e.g., Algorithm 1 of <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>). This document led to the implementation of port randomization in the DNS resolvers themselves, rather than in the underlying transport protocols.
</dd>
          <dt pn="section-4.5-2.11">January 2011:</dt>
          <dd pn="section-4.5-2.12">
            <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/> notes that many TCP and UDP implementations result in predictable ephemeral port numbers and also notes that many implementations select port numbers from a small portion of the whole port number space. It recommends the implementation and use of ephemeral port randomization, proposes a number of possible algorithms for port randomization, and also recommends to randomize port numbers over the range 1024-65535.
</dd>
          <dt pn="section-4.5-2.13">March 2016:</dt>
          <dd pn="section-4.5-2.14">
            <xref target="NIST-NTP" format="default" sectionFormat="of" derivedContent="NIST-NTP"/> reports a non-normal distribution of the ephemeral port numbers employed by the NTP clients of an Internet Time Service.
</dd>
          <dt pn="section-4.5-2.15">April 2019:</dt>
          <dd pn="section-4.5-2.16">
            <xref target="draft-gont-ntp-port-randomization-00" format="default" sectionFormat="of" derivedContent="draft-gont-ntp-port-randomization-00"/> notes that some NTP implementations employ the NTP service port (123) as the local port for nonsymmetric modes and aims to update the NTP specification to recommend port randomization in such cases, which is in line with <xref target="RFC6056" format="default" sectionFormat="of" derivedContent="RFC6056"/>. The proposal experiences some pushback in the relevant working group (NTP WG) <xref target="NTP-PORTR" format="default" sectionFormat="of" derivedContent="NTP-PORTR"/> but is finally adopted as a working group item as <xref target="draft-ietf-ntp-port-randomization-00" format="default" sectionFormat="of" derivedContent="draft-ietf-ntp-port-randomization-00"/>.
</dd>
          <dt pn="section-4.5-2.17">August 2021:</dt>
          <dd pn="section-4.5-2.18">
            <xref target="draft-ietf-ntp-port-randomization-08" format="default" sectionFormat="of" derivedContent="draft-ietf-ntp-port-randomization-08"/> is finally published as <xref target="RFC9109" format="default" sectionFormat="of" derivedContent="RFC9109"/>.
</dd>
        </dl>
      </section>
      <section anchor="dns-query-id" numbered="true" toc="include" removeInRFC="false" pn="section-4.6">
        <name slugifiedName="name-dns-id">DNS ID</name>
        <t indent="0" pn="section-4.6-1">The DNS ID <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> can be employed to match DNS replies to outstanding DNS queries.</t>
        <aside pn="section-4.6-2">
          <t indent="0" pn="section-4.6-2.1">NOTE: Some documents refer to the DNS ID as the DNS "Query ID" or "TxID".</t>
        </aside>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.6-3">
          <dt pn="section-4.6-3.1">November 1987:</dt>
          <dd pn="section-4.6-3.2">
            <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> specifies that the DNS ID is a 16-bit identifier assigned by the program that
generates any kind of query and that this identifier is copied in the corresponding reply and can be used by the requester to match up replies to outstanding queries. It does not specify the interoperability requirements for this numeric identifier, nor does it suggest an algorithm for generating it.</dd>
          <dt pn="section-4.6-3.3">August 1993:</dt>
          <dd pn="section-4.6-3.4">
            <xref target="Schuba1993" format="default" sectionFormat="of" derivedContent="Schuba1993"/> describes DNS cache poisoning attacks that require the attacker to guess the DNS ID.</dd>
          <dt pn="section-4.6-3.5">June 1995:</dt>
          <dd pn="section-4.6-3.6">
            <xref target="Vixie1995" format="default" sectionFormat="of" derivedContent="Vixie1995"/> suggests that both the UDP source port and the DNS ID of query packets should be randomized, although that might not provide enough entropy to prevent an attacker from guessing these values.</dd>
          <dt pn="section-4.6-3.7">April 1997:</dt>
          <dd pn="section-4.6-3.8">
            <xref target="Arce1997" format="default" sectionFormat="of" derivedContent="Arce1997"/> finds that implementations employ predictable UDP source ports and predictable DNS IDs and argues that both should be randomized.</dd>
          <dt pn="section-4.6-3.9">November 2002:</dt>
          <dd pn="section-4.6-3.10">
            <xref target="Sacramento2002" format="default" sectionFormat="of" derivedContent="Sacramento2002"/> finds that, by spoofing multiple requests for the same domain name from different IP addresses, an attacker may guess the DNS ID employed for a victim with a high probability of success, thus allowing for DNS cache poisoning attacks.</dd>
          <dt pn="section-4.6-3.11">March 2007:</dt>
          <dd pn="section-4.6-3.12">
            <xref target="Klein2007c" format="default" sectionFormat="of" derivedContent="Klein2007c"/> finds that the Microsoft Windows DNS server generates predictable DNS ID values.
	  </dd>
          <dt pn="section-4.6-3.13">July 2007:</dt>
          <dd pn="section-4.6-3.14">
            <xref target="Klein2007b" format="default" sectionFormat="of" derivedContent="Klein2007b"/> finds that a popular DNS server software (BIND 9) that randomizes the DNS ID is still subject to DNS cache poisoning attacks by forging a large number of queries and leveraging the birthday paradox.
</dd>
          <dt pn="section-4.6-3.15">October 2007:</dt>
          <dd pn="section-4.6-3.16">
            <xref target="Klein2007" format="default" sectionFormat="of" derivedContent="Klein2007"/> finds that OpenBSD's DNS software (based on the BIND DNS server of the Internet Systems Consortium (ISC)) generates predictable DNS ID values.
</dd>
          <dt pn="section-4.6-3.17">January 2009:</dt>
          <dd pn="section-4.6-3.18">
            <xref target="RFC5452" format="default" sectionFormat="of" derivedContent="RFC5452"/> is published, requiring resolvers to randomize the DNS ID of queries and to verify that the DNS ID of a reply matches that of the DNS query as part of the DNS reply validation process.
</dd>
          <dt pn="section-4.6-3.19">May 2010:</dt>
          <dd pn="section-4.6-3.20">
            <xref target="Economou2010" format="default" sectionFormat="of" derivedContent="Economou2010"/> finds that the Windows SMTP Service implements its own DNS resolver that results in predictable DNS ID values. Additionally, it fails to validate that the DNS ID of a reply matches that of the DNS query that supposedly elicited it.
</dd>
        </dl>
      </section>
    </section>
    <section anchor="conclusions" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-conclusions">Conclusions</name>
      <t indent="0" pn="section-5-1">
   For more than 30 years, a large number of implementations of IETF protocols have been subject to a variety of attacks, with
   effects ranging from Denial of Service (DoS) or data injection to
   information leakages that could be exploited for pervasive monitoring
   <xref target="RFC7258" format="default" sectionFormat="of" derivedContent="RFC7258"/>.  The root cause of these issues has been, in many cases, the poor selection of transient numeric identifiers in such protocols, usually as a result of insufficient or misleading specifications.
</t>
      <t indent="0" pn="section-5-2">
   While it is generally possible to identify an algorithm that can
   satisfy the  interoperability requirements for a given transient
   numeric identifier, this document provides empirical evidence that
   doing so without negatively affecting the security and/or privacy
   properties of the aforementioned protocols is nontrivial. It is thus
   evident that advice in this area is warranted.
</t>
      <t indent="0" pn="section-5-3">
   <xref target="RFC9416" format="default" sectionFormat="of" derivedContent="RFC9416"/> aims at requiring future
   IETF protocol specifications to contain analysis of the security and
   privacy properties of any transient numeric identifiers specified by
   the protocol and to recommend an algorithm for the generation
   of such transient numeric identifiers. <xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/> specifies a number of sample algorithms for generating
   transient numeric identifiers with specific interoperability
   requirements and failure severities. 
</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">This document has no IANA actions.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">This document analyzes the timeline of the specification and implementation of the transient numeric identifiers of some sample IETF protocols and how the security and privacy properties of such protocols have been affected as a result of it. It provides concrete evidence that advice in this area is warranted.</t>
      <t indent="0" pn="section-7-2"><xref target="RFC9415" format="default" sectionFormat="of" derivedContent="RFC9415"/> analyzes and categorizes transient numeric identifiers based on their interoperability requirements and their associated failure severities and recommends possible algorithms that can be employed to comply with those requirements without negatively affecting the security and privacy properties of the corresponding protocols.</t>
      <t indent="0" pn="section-7-3"><xref target="RFC9416" format="default" sectionFormat="of" derivedContent="RFC9416"/> formally requires IETF protocol specifications to specify the interoperability requirements for their transient numeric identifiers, to do a warranted vulnerability assessment of such transient numeric identifiers, and to recommend possible algorithms for their generation, such that the interoperability requirements are complied with, while any negative security or privacy properties of these transient numeric identifiers are mitigated.</t>
    </section>
  </middle>
  <back>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc768" quoteTitle="true" derivedAnchor="RFC0768">
          <front>
            <title>User Datagram Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="August" year="1980"/>
          </front>
          <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/>
          <seriesInfo name="DOI" value="10.17487/RFC0768"/>
        </reference>
        <reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc791" quoteTitle="true" derivedAnchor="RFC0791">
          <front>
            <title>Internet Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="791"/>
          <seriesInfo name="DOI" value="10.17487/RFC0791"/>
        </reference>
        <reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc793" quoteTitle="true" derivedAnchor="RFC0793">
          <front>
            <title>Transmission Control Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="RFC" value="793"/>
          <seriesInfo name="DOI" value="10.17487/RFC0793"/>
        </reference>
        <reference anchor="RFC1323" target="https://www.rfc-editor.org/info/rfc1323" quoteTitle="true" derivedAnchor="RFC1323">
          <front>
            <title>TCP Extensions for High Performance</title>
            <author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
            <author fullname="R. Braden" initials="R." surname="Braden"/>
            <author fullname="D. Borman" initials="D." surname="Borman"/>
            <date month="May" year="1992"/>
            <abstract>
              <t indent="0">This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1323"/>
          <seriesInfo name="DOI" value="10.17487/RFC1323"/>
        </reference>
        <reference anchor="RFC1883" target="https://www.rfc-editor.org/info/rfc1883" quoteTitle="true" derivedAnchor="RFC1883">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="December" year="1995"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1883"/>
          <seriesInfo name="DOI" value="10.17487/RFC1883"/>
        </reference>
        <reference anchor="RFC1884" target="https://www.rfc-editor.org/info/rfc1884" quoteTitle="true" derivedAnchor="RFC1884">
          <front>
            <title>IP Version 6 Addressing Architecture</title>
            <author fullname="R. Hinden" initials="R." role="editor" surname="Hinden"/>
            <author fullname="S. Deering" initials="S." role="editor" surname="Deering"/>
            <date month="December" year="1995"/>
            <abstract>
              <t indent="0">This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1884"/>
          <seriesInfo name="DOI" value="10.17487/RFC1884"/>
        </reference>
        <reference anchor="RFC2073" target="https://www.rfc-editor.org/info/rfc2073" quoteTitle="true" derivedAnchor="RFC2073">
          <front>
            <title>An IPv6 Provider-Based Unicast Address Format</title>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="P. Lothberg" initials="P." surname="Lothberg"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="January" year="1997"/>
            <abstract>
              <t indent="0">This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2073"/>
          <seriesInfo name="DOI" value="10.17487/RFC2073"/>
        </reference>
        <reference anchor="RFC2374" target="https://www.rfc-editor.org/info/rfc2374" quoteTitle="true" derivedAnchor="RFC2374">
          <front>
            <title>An IPv6 Aggregatable Global Unicast Address Format</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="M. O'Dell" initials="M." surname="O'Dell"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <date month="July" year="1998"/>
            <abstract>
              <t indent="0">This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2374"/>
          <seriesInfo name="DOI" value="10.17487/RFC2374"/>
        </reference>
        <reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc2460" quoteTitle="true" derivedAnchor="RFC2460">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="December" year="1998"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2460"/>
          <seriesInfo name="DOI" value="10.17487/RFC2460"/>
        </reference>
        <reference anchor="RFC3041" target="https://www.rfc-editor.org/info/rfc3041" quoteTitle="true" derivedAnchor="RFC3041">
          <front>
            <title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="R. Draves" initials="R." surname="Draves"/>
            <date month="January" year="2001"/>
            <abstract>
              <t indent="0">This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3041"/>
          <seriesInfo name="DOI" value="10.17487/RFC3041"/>
        </reference>
        <reference anchor="RFC3587" target="https://www.rfc-editor.org/info/rfc3587" quoteTitle="true" derivedAnchor="RFC3587">
          <front>
            <title>IPv6 Global Unicast Address Format</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
            <date month="August" year="2003"/>
            <abstract>
              <t indent="0">This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3587"/>
          <seriesInfo name="DOI" value="10.17487/RFC3587"/>
        </reference>
        <reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4291" quoteTitle="true" derivedAnchor="RFC4291">
          <front>
            <title>IP Version 6 Addressing Architecture</title>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <date month="February" year="2006"/>
            <abstract>
              <t indent="0">This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
              <t indent="0">This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4291"/>
          <seriesInfo name="DOI" value="10.17487/RFC4291"/>
        </reference>
        <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4862" quoteTitle="true" derivedAnchor="RFC4862">
          <front>
            <title>IPv6 Stateless Address Autoconfiguration</title>
            <author fullname="S. Thomson" initials="S." surname="Thomson"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
            <date month="September" year="2007"/>
            <abstract>
              <t indent="0">This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4862"/>
          <seriesInfo name="DOI" value="10.17487/RFC4862"/>
        </reference>
        <reference anchor="RFC4941" target="https://www.rfc-editor.org/info/rfc4941" quoteTitle="true" derivedAnchor="RFC4941">
          <front>
            <title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="R. Draves" initials="R." surname="Draves"/>
            <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
            <date month="September" year="2007"/>
            <abstract>
              <t indent="0">Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4941"/>
          <seriesInfo name="DOI" value="10.17487/RFC4941"/>
        </reference>
        <reference anchor="RFC5452" target="https://www.rfc-editor.org/info/rfc5452" quoteTitle="true" derivedAnchor="RFC5452">
          <front>
            <title>Measures for Making DNS More Resilient against Forged Answers</title>
            <author fullname="A. Hubert" initials="A." surname="Hubert"/>
            <author fullname="R. van Mook" initials="R." surname="van Mook"/>
            <date month="January" year="2009"/>
            <abstract>
              <t indent="0">The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder.</t>
              <t indent="0">Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.</t>
              <t indent="0">By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5452"/>
          <seriesInfo name="DOI" value="10.17487/RFC5452"/>
        </reference>
        <reference anchor="RFC6056" target="https://www.rfc-editor.org/info/rfc6056" quoteTitle="true" derivedAnchor="RFC6056">
          <front>
            <title>Recommendations for Transport-Protocol Port Randomization</title>
            <author fullname="M. Larsen" initials="M." surname="Larsen"/>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="January" year="2011"/>
            <abstract>
              <t indent="0">During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="156"/>
          <seriesInfo name="RFC" value="6056"/>
          <seriesInfo name="DOI" value="10.17487/RFC6056"/>
        </reference>
        <reference anchor="RFC6528" target="https://www.rfc-editor.org/info/rfc6528" quoteTitle="true" derivedAnchor="RFC6528">
          <front>
            <title>Defending against Sequence Number Attacks</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="S. Bellovin" initials="S." surname="Bellovin"/>
            <date month="February" year="2012"/>
            <abstract>
              <t indent="0">This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6528"/>
          <seriesInfo name="DOI" value="10.17487/RFC6528"/>
        </reference>
        <reference anchor="RFC7217" target="https://www.rfc-editor.org/info/rfc7217" quoteTitle="true" derivedAnchor="RFC7217">
          <front>
            <title>A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="April" year="2014"/>
            <abstract>
              <t indent="0">This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7217"/>
          <seriesInfo name="DOI" value="10.17487/RFC7217"/>
        </reference>
        <reference anchor="RFC7323" target="https://www.rfc-editor.org/info/rfc7323" quoteTitle="true" derivedAnchor="RFC7323">
          <front>
            <title>TCP Extensions for High Performance</title>
            <author fullname="D. Borman" initials="D." surname="Borman"/>
            <author fullname="B. Braden" initials="B." surname="Braden"/>
            <author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
            <author fullname="R. Scheffenegger" initials="R." role="editor" surname="Scheffenegger"/>
            <date month="September" year="2014"/>
            <abstract>
              <t indent="0">This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.</t>
              <t indent="0">This document obsoletes RFC 1323 and describes changes from it.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7323"/>
          <seriesInfo name="DOI" value="10.17487/RFC7323"/>
        </reference>
        <reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200" quoteTitle="true" derivedAnchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC8415" target="https://www.rfc-editor.org/info/rfc8415" quoteTitle="true" derivedAnchor="RFC8415">
          <front>
            <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
            <author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
            <author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
            <author fullname="B. Volz" initials="B." surname="Volz"/>
            <author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="S. Jiang" initials="S." surname="Jiang"/>
            <author fullname="T. Lemon" initials="T." surname="Lemon"/>
            <author fullname="T. Winters" initials="T." surname="Winters"/>
            <date month="November" year="2018"/>
            <abstract>
              <t indent="0">This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).</t>
              <t indent="0">This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8415"/>
          <seriesInfo name="DOI" value="10.17487/RFC8415"/>
        </reference>
        <reference anchor="RFC9293" target="https://www.rfc-editor.org/info/rfc9293" quoteTitle="true" derivedAnchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Arce1997" target="http://www.openbsd.org/advisories/sni_12_resolverid.txt" quoteTitle="true" derivedAnchor="Arce1997">
          <front>
            <title>BIND Vulnerabilities and Solutions</title>
            <author initials="I." surname="Arce" fullname="Ivan Arce">
              <organization showOnFrontPage="true">Core Seguridad del Informacion</organization>
            </author>
            <author initials="E." surname="Kargieman" fullname="Emiliano Kargieman">
              <organization showOnFrontPage="true">Core Seguridad del Informacion</organization>
            </author>
            <date year="1997" month="April"/>
          </front>
        </reference>
        <reference anchor="Bellovin1989" target="https://www.cs.columbia.edu/~smb/papers/ipext.pdf" quoteTitle="true" derivedAnchor="Bellovin1989">
          <front>
            <title>Security Problems in the TCP/IP Protocol Suite</title>
            <author initials="S." surname="Bellovin" fullname="S.M. Bellovin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1989" month="April"/>
          </front>
          <refcontent>Computer Communications Review, vol. 19, no. 2, pp. 32-48</refcontent>
        </reference>
        <reference anchor="Bellovin2002" target="https://www.cs.columbia.edu/~smb/papers/fnat.pdf" quoteTitle="true" derivedAnchor="Bellovin2002">
          <front>
            <title>A Technique for Counting NATted Hosts</title>
            <author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="November"/>
          </front>
          <refcontent>IMW'02, Marseille, France</refcontent>
          <seriesInfo name="DOI" value="10.1145/637201.637243"/>
        </reference>
        <reference anchor="CERT2001" target="https://resources.sei.cmu.edu/asset_files/WhitePaper/2001_019_001_496192.pdf" quoteTitle="true" derivedAnchor="CERT2001">
          <front>
            <title>CERT Advisory CA-2001-09: Statistical Weaknesses in TCP/IP Initial Sequence Numbers</title>
            <author>
              <organization showOnFrontPage="true">CERT/CC</organization>
            </author>
            <date year="2001" month="May"/>
          </front>
        </reference>
        <reference anchor="draft-cooper-6man-ipv6-address-generation-privacy-00" target="https://www.ietf.org/archive/id/draft-cooper-6man-ipv6-address-generation-privacy-00.txt" quoteTitle="true" derivedAnchor="draft-cooper-6man-ipv6-address-generation-privacy-00">
          <front>
            <title>Privacy Considerations for IPv6 Address Generation Mechanisms</title>
            <author fullname="Alissa Cooper" initials="A." surname="Cooper"/>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Dave Thaler" initials="D." surname="Thaler"/>
            <date day="15" month="July" year="2013"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-cooper-6man-ipv6-address-generation-privacy-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-eddy-rfc793bis-04" target="https://www.ietf.org/archive/id/draft-eddy-rfc793bis-04.txt" quoteTitle="true" derivedAnchor="draft-eddy-rfc793bis-04">
          <front>
            <title>Transmission Control Protocol Specification</title>
            <author fullname="Wesley Eddy" initials="W." surname="Eddy" role="editor"/>
            <date day="25" month="August" year="2014"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-eddy-rfc793bis-04"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-fgont-6man-rfc4941bis-00" target="https://www.ietf.org/archive/id/draft-fgont-6man-rfc4941bis-00.txt" quoteTitle="true" derivedAnchor="draft-fgont-6man-rfc4941bis-00">
          <front>
            <title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
              <organization showOnFrontPage="true">Ericsson Research</organization>
            </author>
            <author fullname="Dr. Thomas Narten" initials="T." surname="Narten">
              <organization showOnFrontPage="true">IBM Corporation</organization>
            </author>
            <author fullname="Richard P. Draves" initials="R." surname="Draves">
              <organization showOnFrontPage="true">Microsoft Research</organization>
            </author>
            <date day="25" month="March" year="2018"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-fgont-6man-rfc4941bis-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-6man-address-usage-recommendations-00" target="https://www.ietf.org/archive/id/draft-gont-6man-address-usage-recommendations-00.txt" quoteTitle="true" derivedAnchor="draft-gont-6man-address-usage-recommendations-00">
          <front>
            <title>IPv6 Address Usage Recommendations</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Will (Shucheng) LIU" initials="W." surname="LIU"/>
            <date day="27" month="May" year="2016"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-6man-address-usage-recommendations-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-6man-non-stable-iids-00" target="https://www.ietf.org/archive/id/draft-gont-6man-non-stable-iids-00.txt" quoteTitle="true" derivedAnchor="draft-gont-6man-non-stable-iids-00">
          <front>
            <title>Recommendation on Non-Stable IPv6 Interface Identifiers</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Will (Shucheng) Liu" initials="W." surname="Liu"/>
            <date day="23" month="May" year="2016"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-6man-non-stable-iids-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-6man-predictable-fragment-id-00" target="https://www.ietf.org/archive/id/draft-gont-6man-predictable-fragment-id-00.txt" quoteTitle="true" derivedAnchor="draft-gont-6man-predictable-fragment-id-00">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="15" month="December" year="2011"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-6man-predictable-fragment-id-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-6man-predictable-fragment-id-03" target="https://www.ietf.org/archive/id/draft-gont-6man-predictable-fragment-id-03.txt" quoteTitle="true" derivedAnchor="draft-gont-6man-predictable-fragment-id-03">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="9" month="January" year="2013"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-6man-predictable-fragment-id-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-6man-stable-privacy-addresses-00" target="https://www.ietf.org/archive/id/draft-gont-6man-stable-privacy-addresses-00.txt" quoteTitle="true" derivedAnchor="draft-gont-6man-stable-privacy-addresses-00">
          <front>
            <title>A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="15" month="December" year="2011"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-6man-stable-privacy-addresses-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-6man-stable-privacy-addresses-01" target="https://www.ietf.org/archive/id/draft-gont-6man-stable-privacy-addresses-01.txt" quoteTitle="true" derivedAnchor="draft-gont-6man-stable-privacy-addresses-01">
          <front>
            <title>A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="31" month="March" year="2012"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-6man-stable-privacy-addresses-01"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-ntp-port-randomization-00" target="https://www.ietf.org/archive/id/draft-gont-ntp-port-randomization-00.txt" quoteTitle="true" derivedAnchor="draft-gont-ntp-port-randomization-00">
          <front>
            <title>Port Randomization in the Network Time Protocol Version 4</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Guillermo Gont" initials="G." surname="Gont"/>
            <date day="16" month="April" year="2019"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-ntp-port-randomization-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-opsec-ipv6-host-scanning-02" target="https://www.ietf.org/archive/id/draft-gont-opsec-ipv6-host-scanning-02.txt" quoteTitle="true" derivedAnchor="draft-gont-opsec-ipv6-host-scanning-02">
          <front>
            <title>Network Reconnaissance in IPv6 Networks</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Tim Chown" initials="T." surname="Chown"/>
            <date day="23" month="October" year="2012"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-opsec-ipv6-host-scanning-02"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-gont-predictable-numeric-ids-03" target="https://datatracker.ietf.org/doc/html/draft-gont-predictable-numeric-ids-03" quoteTitle="true" derivedAnchor="draft-gont-predictable-numeric-ids-03">
          <front>
            <title>Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols</title>
            <author initials="F." surname="Gont" fullname="Fernando Gont"> </author>
            <author initials="I." surname="Arce" fullname="Ivan Arce">
              <organization showOnFrontPage="true">Quarkslab</organization>
            </author>
            <date month="March" day="11" year="2019"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-predictable-numeric-ids-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-default-iids-00" target="https://www.ietf.org/archive/id/draft-ietf-6man-default-iids-00.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-default-iids-00">
          <front>
            <title>Recommendation on Stable IPv6 Interface Identifiers</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Alissa Cooper" initials="A." surname="Cooper"/>
            <author fullname="Dave Thaler" initials="D." surname="Thaler"/>
            <author fullname="Will (Shucheng) Liu" initials="W." surname="Liu"/>
            <date day="24" month="January" year="2014"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-default-iids-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-default-iids-16" target="https://www.ietf.org/archive/id/draft-ietf-6man-default-iids-16.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-default-iids-16">
          <front>
            <title>Recommendation on Stable IPv6 Interface Identifiers</title>
            <author initials="F." surname="Gont" fullname="Fernando Gont"> </author>
            <author initials="A." surname="Cooper" fullname="Alissa Cooper">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <author initials="D." surname="Thaler" fullname="Dave Thaler">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author initials="W." surname="LIU" fullname="Will (Shucheng) LIU">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <date month="September" day="28" year="2016"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-default-iids-16"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-ipv6-address-generation-privacy-08" target="https://www.ietf.org/archive/id/draft-ietf-6man-ipv6-address-generation-privacy-08.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-ipv6-address-generation-privacy-08">
          <front>
            <title>Privacy Considerations for IPv6 Address Generation Mechanisms</title>
            <author fullname="Alissa Cooper" initials="A." surname="Cooper"/>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Dave Thaler" initials="D." surname="Thaler"/>
            <date day="23" month="September" year="2015"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-ipv6-address-generation-privacy-08"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-predictable-fragment-id-00" target="https://www.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-00.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-predictable-fragment-id-00">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="22" month="March" year="2013"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-id-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-predictable-fragment-id-01" target="https://www.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-01.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-predictable-fragment-id-01">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="29" month="April" year="2014"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-id-01"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-predictable-fragment-id-02" target="https://datatracker.ietf.org/doc/html/draft-ietf-6man-predictable-fragment-id-02" quoteTitle="true" derivedAnchor="draft-ietf-6man-predictable-fragment-id-02">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author initials="F." surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="December" day="19" year="2014"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-id-02"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-predictable-fragment-id-08" target="https://www.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-08.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-predictable-fragment-id-08">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="9" month="June" year="2015"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-id-08"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-predictable-fragment-id-10" target="https://www.ietf.org/archive/id/draft-ietf-6man-predictable-fragment-id-10.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-predictable-fragment-id-10">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="9" month="October" year="2015"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-predictable-fragment-id-10"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-rfc2460bis-05" target="https://www.ietf.org/archive/id/draft-ietf-6man-rfc2460bis-05.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-rfc2460bis-05">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="Stephen E. Deering" initials="S." surname="Deering"/>
            <author fullname="Robert M. Hinden" initials="R." surname="Hinden"/>
            <date day="28" month="June" year="2016"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc2460bis-05"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-rfc2460bis-13" target="https://www.ietf.org/archive/id/draft-ietf-6man-rfc2460bis-13.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-rfc2460bis-13">
          <front>
            <title>draft-ietf-6man-rfc2460bis-13</title>
            <author fullname="Stephen E. Deering" initials="S." surname="Deering"/>
            <author fullname="Robert M. Hinden" initials="R." surname="Hinden"/>
            <date day="19" month="May" year="2017"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc2460bis-13"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-rfc4941bis-00" target="https://www.ietf.org/archive/id/draft-ietf-6man-rfc4941bis-00.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-rfc4941bis-00">
          <front>
            <title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
              <organization showOnFrontPage="true">Ericsson Research</organization>
            </author>
            <author fullname="Dr. Thomas Narten" initials="T." surname="Narten">
              <organization showOnFrontPage="true">IBM Corporation</organization>
            </author>
            <author fullname="Richard P. Draves" initials="R." surname="Draves">
              <organization showOnFrontPage="true">Microsoft Research</organization>
            </author>
            <date day="2" month="July" year="2018"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc4941bis-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-rfc4941bis-12" target="https://www.ietf.org/archive/id/draft-ietf-6man-rfc4941bis-12.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-rfc4941bis-12">
          <front>
            <title>Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6</title>
            <author initials="F." surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true">SI6 Networks</organization>
            </author>
            <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
              <organization showOnFrontPage="true">Kaloom</organization>
            </author>
            <author initials="T." surname="Narten" fullname="Dr. Thomas Narten"> </author>
            <author initials="R." surname="Draves" fullname="Richard P. Draves">
              <organization showOnFrontPage="true">Microsoft Research</organization>
            </author>
            <date month="November" day="2" year="2020"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc4941bis-12"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-stable-privacy-addresses-00" target="https://www.ietf.org/archive/id/draft-ietf-6man-stable-privacy-addresses-00.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-stable-privacy-addresses-00">
          <front>
            <title>A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="18" month="May" year="2012"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-stable-privacy-addresses-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-6man-stable-privacy-addresses-17" target="https://www.ietf.org/archive/id/draft-ietf-6man-stable-privacy-addresses-17.txt" quoteTitle="true" derivedAnchor="draft-ietf-6man-stable-privacy-addresses-17">
          <front>
            <title>A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <date day="27" month="January" year="2014"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6man-stable-privacy-addresses-17"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-ntp-port-randomization-00" target="https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-00.txt" quoteTitle="true" derivedAnchor="draft-ietf-ntp-port-randomization-00">
          <front>
            <title>Port Randomization in the Network Time Protocol Version 4</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Guillermo Gont" initials="G." surname="Gont"/>
            <author fullname="Miroslav Lichvar" initials="M." surname="Lichvar"/>
            <date day="22" month="October" year="2019"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ntp-port-randomization-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-ntp-port-randomization-08" target="https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-08.txt" quoteTitle="true" derivedAnchor="draft-ietf-ntp-port-randomization-08">
          <front>
            <title>Port Randomization in the Network Time Protocol Version 4</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Guillermo Gont" initials="G." surname="Gont"/>
            <author fullname="Miroslav Lichvar" initials="M." surname="Lichvar"/>
            <date day="10" month="June" year="2021"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ntp-port-randomization-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-ntp-refid-updates-00" target="https://www.ietf.org/archive/id/draft-ietf-ntp-refid-updates-00.txt" quoteTitle="true" derivedAnchor="draft-ietf-ntp-refid-updates-00">
          <front>
            <title>Network Time Protocol REFID Updates</title>
            <author fullname="Harlan Stenn" initials="H." surname="Stenn"/>
            <author fullname="Sharon Goldberg" initials="S." surname="Goldberg"/>
            <date day="13" month="November" year="2016"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ntp-refid-updates-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-ietf-opsec-ipv6-host-scanning-08" target="https://www.ietf.org/archive/id/draft-ietf-opsec-ipv6-host-scanning-08.txt" quoteTitle="true" derivedAnchor="draft-ietf-opsec-ipv6-host-scanning-08">
          <front>
            <title>Network Reconnaissance in IPv6 Networks</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont"/>
            <author fullname="Tim Chown" initials="T." surname="Chown"/>
            <date day="28" month="August" year="2015"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-opsec-ipv6-host-scanning-08"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="draft-stenn-ntp-not-you-refid-00" target="https://www.ietf.org/archive/id/draft-stenn-ntp-not-you-refid-00.txt" quoteTitle="true" derivedAnchor="draft-stenn-ntp-not-you-refid-00">
          <front>
            <title>Network Time Protocol Not You REFID</title>
            <author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
              <organization showOnFrontPage="true">Boston University</organization>
            </author>
            <author fullname="Harlan Stenn" initials="H." surname="Stenn">
              <organization showOnFrontPage="true">Network Time Foundation</organization>
            </author>
            <date day="8" month="July" year="2016"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-stenn-ntp-not-you-refid-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="Economou2010" target="https://www.coresecurity.com/core-labs/advisories/core-2010-0424-windows-smtp-dns-query-id-bugs" quoteTitle="true" derivedAnchor="Economou2010">
          <front>
            <title>Windows SMTP Service DNS query Id vulnerabilities</title>
            <author initials="N." surname="Economou" fullname="Nicolas Economou">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2010"/>
          </front>
          <refcontent>Advisory ID Internal CORE-2010-0427</refcontent>
        </reference>
        <reference anchor="Fyodor2002" target="https://nmap.org/presentations/CanSecWest03/CD_Content/idlescan_paper/idlescan.html" quoteTitle="true" derivedAnchor="Fyodor2002">
          <front>
            <title>Idle scanning and related IP ID games</title>
            <author>
              <organization showOnFrontPage="true">Fyodor</organization>
            </author>
            <date year="2002" month="September"/>
          </front>
        </reference>
        <reference anchor="Gont-NTP" target="https://mailarchive.ietf.org/arch/msg/ntp/NkfTHxUUOdp14Agh3h1IPqfcRRg" quoteTitle="true" derivedAnchor="Gont-NTP">
          <front>
            <title>[Ntp] Comments on draft-ietf-ntp-refid-updates-05</title>
            <author initials="F." surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="16" month="April" year="2019"/>
          </front>
          <refcontent>message to the IETF NTP mailing list</refcontent>
        </reference>
        <reference anchor="Gont2011" target="https://www.si6networks.com/files/presentations/hip2011/fgont-hip2011-hacking-ipv6-networks.pdf" quoteTitle="true" derivedAnchor="Gont2011">
          <front>
            <title>Hacking IPv6 Networks (training course)</title>
            <author initials="F." surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="June" year="2011"/>
          </front>
          <refcontent>Hack In Paris 2011 Conference, Paris, France</refcontent>
        </reference>
        <reference anchor="Gont2012" target="https://www.si6networks.com/files/presentations/bsdcan2012/fgont-bsdcan2012-recent-advances-in-ipv6-security.pdf" quoteTitle="true" derivedAnchor="Gont2012">
          <front>
            <title>Recent Advances in IPv6 Security</title>
            <author initials="F." surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2012"/>
          </front>
          <refcontent>BSDCan 2012 Conference, Ottawa, Canada</refcontent>
        </reference>
        <reference anchor="Gont2013" target="https://lists.si6networks.com/pipermail/ipv6hackers/2013-February/000947.html" quoteTitle="true" derivedAnchor="Gont2013">
          <front>
            <title>Beta release of the SI6 Network's IPv6 Toolkit (help wanted!)</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont">
    </author>
            <date day="11" year="2013" month="February"/>
          </front>
          <refcontent>message to the IPv6 Hackers mailing list</refcontent>
        </reference>
        <reference anchor="IANA-PROT" target="https://www.iana.org/protocols" quoteTitle="true" derivedAnchor="IANA-PROT">
          <front>
            <title>Protocol Registries</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="IPID-DEV" target="https://arxiv.org/pdf/1906.10478.pdf" quoteTitle="true" derivedAnchor="IPID-DEV">
          <front>
            <title>From IP ID to Device ID and KASLR Bypass (Extended Version)</title>
            <author initials="A." surname="Klein" fullname="Amit Klein">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Pinkas" fullname="Benny Pinkas">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="October"/>
          </front>
          <seriesInfo name="DOI" value="10.48550/arXiv.1906.10478"/>
        </reference>
        <reference anchor="IPv6-Toolkit" target="https://www.si6networks.com/tools/ipv6toolkit" quoteTitle="true" derivedAnchor="IPv6-Toolkit">
          <front>
            <title>IPv6 Toolkit</title>
            <author>
              <organization showOnFrontPage="true">SI6 Networks</organization>
            </author>
          </front>
        </reference>
        <reference anchor="Kaminsky2008" target="https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf" quoteTitle="true" derivedAnchor="Kaminsky2008">
          <front>
            <title>Black Ops 2008: It's The End Of The Cache As We Know It</title>
            <author initials="D." surname="Kaminsky" fullname="Dan Kaminsky">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="August" year="2008"/>
          </front>
        </reference>
        <reference anchor="Klein2007" target="https://dl.packetstormsecurity.net/papers/attack/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf" quoteTitle="true" derivedAnchor="Klein2007">
          <front>
            <title>OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability</title>
            <author initials="A." surname="Klein" fullname="Amit Klein">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="October"/>
          </front>
        </reference>
        <reference anchor="Klein2007b" target="https://citeseerx.ist.psu.edu/doc/10.1.1.86.4474" quoteTitle="true" derivedAnchor="Klein2007b">
          <front>
            <title>BIND 9 DNS Cache Poisoning</title>
            <author initials="A." surname="Klein" fullname="Amit Klein">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="March" year="2007"/>
          </front>
        </reference>
        <reference anchor="Klein2007c" target="https://dl.packetstormsecurity.net/papers/attack/Windows_DNS_Cache_Poisoning.pdf" quoteTitle="true" derivedAnchor="Klein2007c">
          <front>
            <title>Windows DNS Server Cache Poisoning</title>
            <author initials="A." surname="Klein" fullname="Amit Klein">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="March" year="2007"/>
          </front>
        </reference>
        <reference anchor="Morbitzer2013" target="https://seclists.org/nmap-dev/2013/q2/394" quoteTitle="true" derivedAnchor="Morbitzer2013">
          <front>
            <title>[PATCH] TCP Idle Scan in IPv6</title>
            <author initials="M." surname="Morbitzer" fullname="Mathias Morbitzer">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="3" year="2013" month="June"/>
          </front>
          <refcontent>message to the nmap-dev mailing list</refcontent>
        </reference>
        <reference anchor="Morris1985" target="https://pdos.csail.mit.edu/~rtm/papers/117.pdf" quoteTitle="true" derivedAnchor="Morris1985">
          <front>
            <title>A Weakness in the 4.2BSD UNIX TCP/IP Software</title>
            <author initials="R." surname="Morris" fullname="Robert Morris">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1985" month="February"/>
          </front>
          <refcontent>CSTR 117, AT&amp;T Bell Laboratories, Murray Hill, NJ</refcontent>
        </reference>
        <reference anchor="NIST-NTP" target="https://tf.nist.gov/general/pdf/2818.pdf" quoteTitle="true" derivedAnchor="NIST-NTP">
          <front>
            <title>Usage Analysis of the NIST Internet Time Service</title>
            <author initials="J." surname="Sherman" fullname="Jeff A. Sherman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Levine" fullname="Judah Levine">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="March"/>
          </front>
          <refcontent>Journal of Research of the National Institute of Standards and Technology, Volume 121</refcontent>
        </reference>
        <reference anchor="NTP-PORTR" target="https://mailarchive.ietf.org/arch/msg/ntp/xSCu5Vhb3zoWcqEjUMmzP8pOdW4/" quoteTitle="true" derivedAnchor="NTP-PORTR">
          <front>
            <title>[Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)</title>
            <author fullname="Fernando Gont" initials="F." surname="Gont">
            </author>
            <date day="21" month="May" year="2019"/>
          </front>
          <refcontent>message to the IETF NTP mailing list</refcontent>
        </reference>
        <reference anchor="OpenBSD-IPv4-ID" target="https://cvsweb.openbsd.org/src/sys/netinet/ip_id.c?rev=1.1" quoteTitle="true" derivedAnchor="OpenBSD-IPv4-ID">
          <front>
            <title>Randomization of the IPv4 Identification field</title>
            <author>
              <organization showOnFrontPage="true">OpenBSD</organization>
            </author>
            <date month="December" year="1998"/>
          </front>
        </reference>
        <reference anchor="OpenBSD-IPv6-ID" target="https://cvsweb.openbsd.org/src/sys/netinet6/ip6_id.c?rev=1.1" quoteTitle="true" derivedAnchor="OpenBSD-IPv6-ID">
          <front>
            <title>Randomization of the IPv6 Identification field</title>
            <author>
              <organization showOnFrontPage="true">OpenBSD</organization>
            </author>
            <date month="October" year="2003"/>
          </front>
        </reference>
        <reference anchor="OpenBSD-PR" target="https://cvsweb.openbsd.org/src/sys/netinet/in_pcb.c?rev=1.6" quoteTitle="true" derivedAnchor="OpenBSD-PR">
          <front>
            <title>Implementation of port randomization</title>
            <author>
              <organization showOnFrontPage="true">OpenBSD</organization>
            </author>
            <date month="July" year="1996"/>
          </front>
        </reference>
        <reference anchor="OpenBSD-TCP-ISN-H" target="https://cvsweb.openbsd.org/src/sys/netinet/tcp_subr.c?rev=1.97" quoteTitle="true" derivedAnchor="OpenBSD-TCP-ISN-H">
          <front>
            <title>Implementation of RFC1948 for TCP ISN randomization</title>
            <author>
              <organization showOnFrontPage="true">OpenBSD</organization>
            </author>
            <date month="June" year="2007"/>
          </front>
        </reference>
        <reference anchor="OpenBSD-TCP-ISN-I" target="https://cvsweb.openbsd.org/src/sys/netinet/tcp_subr.c?rev=1.6" quoteTitle="true" derivedAnchor="OpenBSD-TCP-ISN-I">
          <front>
            <title>Implementation of TCP ISN randomization based on random increments</title>
            <author>
              <organization showOnFrontPage="true">OpenBSD</organization>
            </author>
            <date month="July" year="1996"/>
          </front>
        </reference>
        <reference anchor="OpenBSD-TCP-ISN-R" target="https://cvsweb.openbsd.org/src/sys/netinet/tcp_subr.c?rev=1.37" quoteTitle="true" derivedAnchor="OpenBSD-TCP-ISN-R">
          <front>
            <title>Implementation of TCP ISN randomization based on simple randomization</title>
            <author>
              <organization showOnFrontPage="true">OpenBSD</organization>
            </author>
            <date month="December" year="2000"/>
          </front>
        </reference>
        <reference anchor="RedHat2011" target="https://rhn.redhat.com/errata/RHSA-2011-1465.html" quoteTitle="true" derivedAnchor="RedHat2011">
          <front>
            <title>RHSA-2011:1465-1 - Security Advisory</title>
            <author>
              <organization showOnFrontPage="true">Red Hat</organization>
            </author>
            <date year="2011" month="November"/>
          </front>
        </reference>
        <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" quoteTitle="true" derivedAnchor="RFC1035">
          <front>
            <title>Domain names - implementation and specification</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t indent="0">This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>
        <reference anchor="RFC1948" target="https://www.rfc-editor.org/info/rfc1948" quoteTitle="true" derivedAnchor="RFC1948">
          <front>
            <title>Defending Against Sequence Number Attacks</title>
            <author fullname="S. Bellovin" initials="S." surname="Bellovin"/>
            <date month="May" year="1996"/>
            <abstract>
              <t indent="0">IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1948"/>
          <seriesInfo name="DOI" value="10.17487/RFC1948"/>
        </reference>
        <reference anchor="RFC5157" target="https://www.rfc-editor.org/info/rfc5157" quoteTitle="true" derivedAnchor="RFC5157">
          <front>
            <title>IPv6 Implications for Network Scanning</title>
            <author fullname="T. Chown" initials="T." surname="Chown"/>
            <date month="March" year="2008"/>
            <abstract>
              <t indent="0">The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5157"/>
          <seriesInfo name="DOI" value="10.17487/RFC5157"/>
        </reference>
        <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905" quoteTitle="true" derivedAnchor="RFC5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
            <author fullname="J. Burbank" initials="J." surname="Burbank"/>
            <author fullname="W. Kasch" initials="W." surname="Kasch"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
        <reference anchor="RFC6274" target="https://www.rfc-editor.org/info/rfc6274" quoteTitle="true" derivedAnchor="RFC6274">
          <front>
            <title>Security Assessment of the Internet Protocol Version 4</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="July" year="2011"/>
            <abstract>
              <t indent="0">This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6274"/>
          <seriesInfo name="DOI" value="10.17487/RFC6274"/>
        </reference>
        <reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc7258" quoteTitle="true" derivedAnchor="RFC7258">
          <front>
            <title>Pervasive Monitoring Is an Attack</title>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="188"/>
          <seriesInfo name="RFC" value="7258"/>
          <seriesInfo name="DOI" value="10.17487/RFC7258"/>
        </reference>
        <reference anchor="RFC7707" target="https://www.rfc-editor.org/info/rfc7707" quoteTitle="true" derivedAnchor="RFC7707">
          <front>
            <title>Network Reconnaissance in IPv6 Networks</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="T. Chown" initials="T." surname="Chown"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7707"/>
          <seriesInfo name="DOI" value="10.17487/RFC7707"/>
        </reference>
        <reference anchor="RFC7721" target="https://www.rfc-editor.org/info/rfc7721" quoteTitle="true" derivedAnchor="RFC7721">
          <front>
            <title>Security and Privacy Considerations for IPv6 Address Generation Mechanisms</title>
            <author fullname="A. Cooper" initials="A." surname="Cooper"/>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7721"/>
          <seriesInfo name="DOI" value="10.17487/RFC7721"/>
        </reference>
        <reference anchor="RFC7739" target="https://www.rfc-editor.org/info/rfc7739" quoteTitle="true" derivedAnchor="RFC7739">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="February" year="2016"/>
            <abstract>
              <t indent="0">IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7739"/>
          <seriesInfo name="DOI" value="10.17487/RFC7739"/>
        </reference>
        <reference anchor="RFC8064" target="https://www.rfc-editor.org/info/rfc8064" quoteTitle="true" derivedAnchor="RFC8064">
          <front>
            <title>Recommendation on Stable IPv6 Interface Identifiers</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="A. Cooper" initials="A." surname="Cooper"/>
            <author fullname="D. Thaler" initials="D." surname="Thaler"/>
            <author fullname="W. Liu" initials="W." surname="Liu"/>
            <date month="February" year="2017"/>
            <abstract>
              <t indent="0">This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8064"/>
          <seriesInfo name="DOI" value="10.17487/RFC8064"/>
        </reference>
        <reference anchor="RFC8981" target="https://www.rfc-editor.org/info/rfc8981" quoteTitle="true" derivedAnchor="RFC8981">
          <front>
            <title>Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <author fullname="R. Draves" initials="R." surname="Draves"/>
            <date month="February" year="2021"/>
            <abstract>
              <t indent="0">This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8981"/>
          <seriesInfo name="DOI" value="10.17487/RFC8981"/>
        </reference>
        <reference anchor="RFC9109" target="https://www.rfc-editor.org/info/rfc9109" quoteTitle="true" derivedAnchor="RFC9109">
          <front>
            <title>Network Time Protocol Version 4: Port Randomization</title>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <author fullname="G. Gont" initials="G." surname="Gont"/>
            <author fullname="M. Lichvar" initials="M." surname="Lichvar"/>
            <date month="August" year="2021"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port. However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9109"/>
          <seriesInfo name="DOI" value="10.17487/RFC9109"/>
        </reference>
        <reference anchor="RFC9415" target="https://www.rfc-editor.org/info/rfc9415" quoteTitle="true" derivedAnchor="RFC9415">
          <front>
            <title>On the Generation of Transient Numeric Identifiers</title>
            <author initials="F" surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I" surname="Arce" fullname="Ivan Arce">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2023" month="July"/>
          </front>
          <seriesInfo name="RFC" value="9415"/>
          <seriesInfo name="DOI" value="10.17487/RFC9415"/>
        </reference>
        <reference anchor="RFC9416" target="https://www.rfc-editor.org/info/rfc9416" quoteTitle="true" derivedAnchor="RFC9416">
          <front>
            <title>Security Considerations for Transient Numeric Identifiers Employed in Network Protocols</title>
            <author initials="F" surname="Gont" fullname="Fernando Gont">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I" surname="Arce" fullname="Ivan Arce">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2023" month="July"/>
          </front>
          <seriesInfo name="BCP" value="72"/>
          <seriesInfo name="RFC" value="9416"/>
          <seriesInfo name="DOI" value="10.17487/RFC9416"/>
        </reference>
        <reference anchor="Sacramento2002" target="https://seclists.org/bugtraq/2002/Nov/331" quoteTitle="true" derivedAnchor="Sacramento2002">
          <front>
            <title>CAIS-ALERT: Vulnerability in the sending requests control of BIND</title>
            <author initials="V." surname="Sacramento" fullname="Vagner Sacramento">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="25" month="November" year="2002"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Sanfilippo1998a" target="http://seclists.org/bugtraq/1998/Dec/48" quoteTitle="true" derivedAnchor="Sanfilippo1998a">
          <front>
            <title>about the ip header id</title>
            <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfilippo">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="14" month="December" year="1998"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Sanfilippo1998b" target="https://seclists.org/bugtraq/1998/Dec/79" quoteTitle="true" derivedAnchor="Sanfilippo1998b">
          <front>
            <title>new tcp scan method</title>
            <author initials="S." surname="Sanfilippo" fullname="Salvatore Sanfilippo">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1998" month="December" day="18"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Sanfilippo1999" target="https://github.com/antirez/hping/raw/master/docs/MORE-FUN-WITH-IPID" quoteTitle="true" derivedAnchor="Sanfilippo1999">
          <front>
            <title>more ip id</title>
            <author initials="S." surname="Sanfilippo" fullname="S. Sanfilippo">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1999" month="November"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Schuba1993" target="http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf" quoteTitle="true" derivedAnchor="Schuba1993">
          <front>
            <title>Addressing Weakness in the Domain Name System Protocol</title>
            <author initials="C." surname="Schuba" fullname="Christoph Schuba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1993" month="August"/>
          </front>
        </reference>
        <reference anchor="Shimomura1995" target="https://www.gont.com.ar/files/post-shimomura-usenet.txt" quoteTitle="true" derivedAnchor="Shimomura1995">
          <front>
            <title>Technical details of the attack described by Markoff in NYT</title>
            <author initials="T." surname="Shimomura" fullname="Tsutomu Shimomura">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="25" year="1995" month="January"/>
          </front>
          <refcontent>message to the USENET comp.security.misc newsgroup</refcontent>
        </reference>
        <reference anchor="Silbersack2005" target="https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.4542&amp;rep=rep1&amp;type=pdf" quoteTitle="true" derivedAnchor="Silbersack2005">
          <front>
            <title>Improving TCP/IP security through randomization without sacrificing interoperability</title>
            <author initials="M." surname="Silbersack" fullname="Michael James Silbersack">
              <organization showOnFrontPage="true">The FreeBSD Project</organization>
            </author>
            <date year="2005" month="January"/>
          </front>
          <refcontent>EuroBSDCon 2005 Conference</refcontent>
        </reference>
        <reference anchor="SUSE2011" target="https://lists.opensuse.org/opensuse-security-announce/2011-12/msg00011.html" quoteTitle="true" derivedAnchor="SUSE2011">
          <front>
            <title>[security-announce] SUSE Security Announcement: Linux kernel security update (SUSE-SA:2011:046)</title>
            <author initials="M." surname="Meissner" fullname="Marcus Meissner">
              <organization showOnFrontPage="true">SUSE</organization>
            </author>
            <date day="13" year="2011" month="December"/>
          </front>
          <refcontent>message to the openSUSE Security Announce mailing list</refcontent>
        </reference>
        <reference anchor="TCPT-uptime" target="https://seclists.org/bugtraq/2001/Mar/182" quoteTitle="true" derivedAnchor="TCPT-uptime">
          <front>
            <title>TCP Timestamping - Obtaining System Uptime Remotely</title>
            <author initials="B." surname="McDanel" fullname="Bret McDanel">
              <organization showOnFrontPage="true">Securiteam</organization>
            </author>
            <date month="March" year="2001"/>
          </front>
          <refcontent>message to the Bugtraq mailing list</refcontent>
        </reference>
        <reference anchor="Ubuntu2011" target="https://ubuntu.com/security/notices/USN-1253-1" quoteTitle="true" derivedAnchor="Ubuntu2011">
          <front>
            <title>USN-1253-1: Linux kernel vulnerabilities</title>
            <author>
              <organization showOnFrontPage="true">Ubuntu</organization>
            </author>
            <date year="2011" month="November"/>
          </front>
        </reference>
        <reference anchor="USCERT2001" target="https://www.kb.cert.org/vuls/id/498440" quoteTitle="true" derivedAnchor="USCERT2001">
          <front>
            <title>Multiple TCP/IP implementations may use statistically predictable initial sequence numbers</title>
            <author>
              <organization showOnFrontPage="true">CERT CC</organization>
            </author>
            <date year="2001" month="March"/>
          </front>
          <refcontent>Vulnerability Note VU#498440</refcontent>
        </reference>
        <reference anchor="Vixie1995" target="https://www.usenix.org/legacy/publications/library/proceedings/security95/full_papers/vixie.pdf" quoteTitle="true" derivedAnchor="Vixie1995">
          <front>
            <title>DNS and BIND Security Issues</title>
            <author initials="P." surname="Vixie" fullname="Paul Vixie">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="June" year="1995"/>
          </front>
          <refcontent>5th Usenix Security Symposium</refcontent>
        </reference>
        <reference anchor="VU-800113" target="https://www.kb.cert.org/vuls/id/800113" quoteTitle="true" derivedAnchor="VU-800113">
          <front>
            <title>Multiple DNS implementations vulnerable to cache poisoning</title>
            <author>
              <organization showOnFrontPage="true">CERT/CC</organization>
            </author>
            <date month="July" year="2008"/>
          </front>
          <refcontent>Vulnerability Note VU#800113</refcontent>
        </reference>
        <reference anchor="Wright1994" quoteTitle="true" derivedAnchor="Wright1994">
          <front>
            <title>TCP/IP Illustrated, Volume 2: The Implementation</title>
            <author initials="G." surname="Wright" fullname="Gary R. Wright">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Stevens" fullname="W. Richard Stevens">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1995" month="February"/>
          </front>
          <refcontent>Addison-Wesley</refcontent>
        </reference>
        <reference anchor="Zalewski2001" target="https://lcamtuf.coredump.cx/oldtcp/tcpseq.html" quoteTitle="true" derivedAnchor="Zalewski2001">
          <front>
            <title>Strange Attractors and TCP/IP Sequence Number Analysis (2001)</title>
            <author initials="M." surname="Zalewski" fullname="M. Zalewski">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001" month="March"/>
          </front>
        </reference>
        <reference anchor="Zalewski2002" target="https://lcamtuf.coredump.cx/newtcp/" quoteTitle="true" derivedAnchor="Zalewski2002">
          <front>
            <title>Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later (2002)</title>
            <author initials="M." surname="Zalewski" fullname="M. Zalewski">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002"/>
          </front>
        </reference>
        <reference anchor="Zalewski2003" target="https://lcamtuf.coredump.cx/ipfrag.txt" quoteTitle="true" derivedAnchor="Zalewski2003">
          <front>
            <title>A new TCP/IP blind data injection technique?</title>
            <author initials="M." surname="Zalewski" fullname="Michal Zalewski">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="December"/>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank (in alphabetical order) <contact fullname="Bernard Aboba"/>, <contact fullname="Dave Crocker"/>, <contact fullname="Spencer Dawkins"/>, <contact fullname="Theo de Raadt"/>, <contact fullname="Sara Dickinson"/>, <contact fullname="Guillermo Gont"/>, <contact fullname="Christian Huitema"/>, <contact fullname="Colin Perkins"/>, <contact fullname="Vincent Roca"/>, <contact fullname="Kris Shrishak"/>, <contact fullname="Joe Touch"/>, <contact fullname="Brian Trammell"/>, and <contact fullname="Christopher Wood"/> for providing valuable comments on earlier versions of this document.</t>
      <t indent="0" pn="section-appendix.a-2">The authors would like to thank (in alphabetical order) <contact fullname="Steven Bellovin"/>, <contact fullname="Joseph Lorenzo Hall"/>, <contact fullname="Gre Norcie"/>, and <contact fullname="Martin Thomson"/> for providing valuable comments on <xref target="draft-gont-predictable-numeric-ids-03" format="default" sectionFormat="of" derivedContent="draft-gont-predictable-numeric-ids-03"/>, on which this document is based.</t>
      <t indent="0" pn="section-appendix.a-3"><xref target="tcp-isns" format="default" sectionFormat="of" derivedContent="Section 4.2"/> of this document borrows text from <xref target="RFC6528" format="default" sectionFormat="of" derivedContent="RFC6528"/>, authored by <contact fullname="Fernando Gont"/> and <contact fullname="Steven Bellovin"/>.</t>
      <t indent="0" pn="section-appendix.a-4">The authors would like to thank <contact fullname="Sara Dickinson"/> and <contact fullname="Christopher Wood"/> for their guidance during the publication process of this document.</t>
      <t indent="0" pn="section-appendix.a-5">The authors would like to thank <contact fullname="Diego Armando Maradona"/> for his magic and inspiration.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Fernando Gont" initials="F." surname="Gont">
        <organization abbrev="SI6 Networks" showOnFrontPage="true">SI6 Networks</organization>
        <address>
          <postal>
            <extaddr>Segurola y Habana</extaddr>
            <street>4310 7mo piso</street>
            <city>Ciudad Autonoma de Buenos Aires</city>
            <country>Argentina</country>
          </postal>
          <email>fgont@si6networks.com</email>
          <uri>https://www.si6networks.com</uri>
        </address>
      </author>
      <author fullname="Ivan Arce" initials="I." surname="Arce">
        <organization abbrev="Quarkslab" showOnFrontPage="true">Quarkslab</organization>
        <address>
          <postal>
            <extaddr>Segurola y Habana</extaddr>
            <street>4310 7mo piso</street>
            <city>Ciudad Autonoma de Buenos Aires</city>
            <country>Argentina</country>
          </postal>
          <email>iarce@quarkslab.com</email>
          <uri>https://www.quarkslab.com</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
