<?xml version="1.0" encoding="utf-8"?>
<!-- 
     draft-rfcxml-general-template-standard-00
  
     This template includes examples of the most commonly used features of RFCXML with comments 
     explaining how to customise them. This template can be quickly turned into an I-D by editing 
     the examples provided. Look for [REPLACE], [REPLACE/DELETE], [CHECK] and edit accordingly.
     Note - 'DELETE' means delete the element or attribute, not just the contents.
     
     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?><!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
<!ENTITY zwsp   "&#8203;">
<!ENTITY nbhy   "&#8209;">
<!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-evan-amateur-radio-ipv6-02" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- [REPLACE] 
       * docName with name of your draft
     [CHECK] 
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN 
-->

  <front>
    <title abbrev="Callsign-Derived IPv6 Interface IDs">Callsign-Derived IPv6 Interface Identifiers for Amateur Radio</title>

    <seriesInfo name="Internet-Draft" value="draft-evan-amateur-radio-ipv6-02"/>

    <author fullname="Evan Pratten" initials="E." surname="Pratten">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
      <!-- Can have more than one author -->

      <!-- all of the following elements are optional -->
      <address>
        <email>evan@ewpratten.com</email>
        <uri>https://ewpratten.com</uri>
      </address>
    </author>

    <date year="2022"/>
    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is 
          not present, the default is "Network Working Group", which is used by the RFC Editor as 
          a nod to the history of the RFC Series. -->

    <keyword>ipv6</keyword>
    <keyword>link-local</keyword>
    <keyword>amateur radio</keyword>
    <keyword>packet radio</keyword>
    <!-- [REPLACE/DELETE]. Multiple allowed.  Keywords are incorporated into HTML output files for 
         use by search engines. -->

    <abstract>
      <t>
        This document presents a process by which IPv6 interface identifiers may be derived from amateur 
        radio callsigns to create unique addresses for packet radio nodes without the need for central coordination.
      </t>
    </abstract>

  </front>

  <middle>

    <section>
      <name>Introduction</name>
      <t>
        When coordinating a global-scale packet radio network, it may not be practical or desireable to 
        require all participating stations to request and/or register their local IP addresses with a central authority.
        The addressing technique presented in this document aims to provide a standard method by which radio nodes 
        can self-assign addresses by utilizing the existing guarantee that all station callsigns are unique.
      </t>

    </section>

    <section>
      <name>Node Addressing</name>
      <t>
        Packet radio stations (also referred to as "nodes") are generally identified via their station callsign 
        followed by an informational number or letter, this suffix is used to describe the type or an arbitrary 
        ID of the station.
      </t>
      <t>
        Unlike other common network protocols used by packet radio nodes, IPv6 <xref target="RFC8200"/>
        does not offer a mechanism for 
        addressing another node by its callsign and ID. This means that an alternate addressing scheme, such as 
        the one defined in this document, is needed to allow nodes to communicate with each other using IPv6.
      </t>

      <section>
        <name>Determining the Address for a Station</name>
        <t>
          To determine a 64 bit long 
          <xref target="RFC4291"/>
          interface ID for a packet radio node, the following steps are taken:
        </t>
        <ol>
          <li>Compute the SHA-256 hash of the station's UPPERCASE callsign.</li>
          <li>Use the first 60 bits of the hash as the first 60 bits of the interface ID.</li>
          <li>Use the final 4 bits of the address' interface ID to store the station's ID.</li>
        </ol>
        <t>
          Using this method to compute the address for a station with the callsign "VA3ZZA" and the ID "10" as a host in the prefix 
          "2001:db8::/64" 
          <xref target="RFC4632"/>
          would result in the station address: "2001:db8::9846:807d:5b56:3a7a".
        </t>
      </section>

      <section>
        <name>Benefits of this method</name>
        <t>
          This method of IP address assignment has several benefits:
        </t>
        <ul>
          <li>
            Callsigns are uniquely assigned to stations by existing governing bodies. Using them as the basis of address 
            creation will ensure a unique base hash for each station.
          </li>
          <li>
            Hashing callsigns instead of trying to plainly hex encode them allows support for excessively long callsigns.
          </li>
          <li>
            Encoding the station ID in the final nibble of the address allows for up to 16 nodes under the same callsign 
            to be assigned addresses within the same /124. This allows address-based access control logic to operate on 
            a whole callsign (first 60 bits of the interface ID) at once, an ability not possible if the ID was also hashed.
          </li>
        </ul>
      </section>

      <section>
        <name>Drawbacks of this method</name>
        <t>
          While it is possible for one node to correlate another's IP address to its station callsign via a lookup table, 
          ideally the raw callsign could be encoded directly into the IPv6 address. Doing so would both allow 
          for a node to easily determine the callsign of a sending station without additional metadata embedded 
          in the received packet, and allow the source address on outgoing packets to be used to satisfy legal 
          station identification requirements.
        </t>
        <t>
          Unfortunately, this is not feasible due to many governments assigning temporary "special event callsigns" 
          to stations. These special callsigns often do not follow the general length restrictions on permanent 
          callsigns, raising the possibility that a station will be assigned a callsign longer than is possible 
          to encode directly in an IPv6 address, thus being un-addressable.
        </t>
      </section>

    </section>

    <section>
      <name>Privacy Considerations</name>
      <t>
        The International Telecommunication Union requires all stations operating in the amateur service to 
        self-identify when transmitting. Various countries also impose further requirements such as the 
        interval and method by which stations must identify themselves. 
      </t>
      <t>
        The legal requirement to identify all transmissions nullifies any privacy benefits gained from other 
        privacy-aware addressing methods such as SLAAC 
        <xref target="RFC7217"/>.
      </t>
    </section>

    <section anchor="IANA">
      <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>This document should not affect the security of the Internet.</t>
    </section>

    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4291.xml"/>
        <!-- The recommended and simplest way to include a well known reference -->

      </references>

      <references>
        <name>Informative References</name>

        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4632.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7217.xml"/>

      </references>
    </references>

    <!-- <section>
      <name>Appendix 1 [REPLACE/DELETE]</name>
      <t>This becomes an Appendix [REPLACE]</t>
    </section> -->

    <!-- <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>This template uses extracts from templates written by Pekka Savola, Elwyn Davies and 
        Henrik Levkowetz. [REPLACE]</t>
    </section> -->

    <!-- <section anchor="Contributors" numbered="false">
      <name>Contributors</name>
      <t>Thanks to all of the contributors. [REPLACE]</t>
    </section> -->

  </back>
</rfc>
