<?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-00" 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="Unique IPv6 GUAs for Amateur Radio">Globally Unique IPv6 Addressing for Amateur Radio</title>

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

    <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 <xref target="RFC2460"/>
        addresses can be uniquely and automatically assigned to amateur 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 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>A Note on Prefix Length</name>
        <t>
          While the addressing method defined in the following section may be applied to nearly any network 
          prefix length, usage of a 64 bit long network portion is strongly encouraged to ensure all 
          implementations are interoperable.
        </t>
      </section>

      <section>
        <name>Determining the Address for a Station</name>
        <t>
          Given an IPv6 prefix with a 64 bit long network portion, the host address for station is calculated via the following steps:
        </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 host portion of the IP address.</li>
          <li>Use the final 4 bits of the address' host portion 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="RFC1519"/>
 
          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 host portion) 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 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.2460.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.1519.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>
