<?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-03" 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 IIDs">A Method for Deriving Stable IPv6 Interface Identifiers from Amateur Radio Callsigns</title>
 
    <seriesInfo name="Internet-Draft" value="draft-evan-amateur-radio-ipv6-03"/>

    <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="2023"/>
    <!-- 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>amateur radio</keyword>
    <keyword>packet radio</keyword>
    <keyword>interface id</keyword>
    <keyword>interface identifier</keyword>
    <!-- [REPLACE/DELETE]. Multiple allowed.  Keywords are incorporated into HTML output files for 
         use by search engines. -->

    <abstract>
      <t>
        This document defines a method for generating stable IPv6 Interface Identifiers for amateur packet 
        radio nodes. 
        
        This method is meant to be an alternative to hardware address based Interface Identifier generation 
        such that the benefits of stable addressing may be achieved even on nodes that have unstable, 
        changing, or experimental networking hardware. 

        Instead of a physically-derived address, this method utilizes a unique hash of the node's 
        government-assigned callsign as the basis for its Interface Identifier.
      </t>
    </abstract>

  </front>

  <middle>

    <section>
      <name>Introduction</name>
      <t>
        This document specifies the steps an amateur packet radio node takes in order to generate a stable 
        and unique IPv6 Interface Identifier (IID) <xref target="RFC2460"/>. The resulting Interface Identifier 
        SHALL be used in conjunction with processes such as (but not limited to) Stateless Address 
        Autoconfiguration (SLAAC) <xref target="RFC4862"/>, DHCPv6 <xref target="RFC3315"/>, or manual configuration 
        to configure IPv6 connectivity on the node.
      </t>
      <t> 
        Callsign-derived Interface Identifier generation requires minimal manual configuration, and when paired with 
        SLAAC may allow a mobile amateur packet radio node to automatically connect to, and communicate with any 
        compliant amateur radio network provided that the node has been configured with a callsign, and is 
        communicating on the correct radio frequency.
      </t>
    </section>

    <section>
      <name>Terminology</name>
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref target="RFC2119"/>.
      </t>
    </section>

    <section>
      <name>Foreword on Node Identification</name>
      <t>
        Amateur packet radio nodes generally identify themselves with a string of ASCII characters comprised of:
      </t>
      <ol>
        <li>
          The station's government-assigned callsign
        </li>
        <li>
          A dash (-)
        </li>
        <li>
          A number ranging from 0 to 15, inclusive. 
          This will be referred to for the remainder of this document as the node's "ID". 
          Stations that do not use a node ID generally will use a "0" in this place.
        </li>
      </ol>
      <t>
        For example, a node operated under the callsign "VA3ZZA" with the node ID of "5" would identify itself on-air as "VA3ZZA-5". 
      </t>
    </section>

    <section>
      <name>The Algorithm</name>
      <t>
        To determine a 64 bit long <xref target="RFC4291"/> Interface Identifier for an amateur packet radio node in 
        conformance with this specification, the following steps MUST be be taken:
      </t>
      <ol>
        <li>Compute the SHA-256 hash of the node's UPPERCASE callsign.</li>
        <li>Use the first 60 bits of the hash as the first 60 bits of the Interface Identifier.</li>
        <li>Use the final 4 bits of the address' Interface Identifier to store the nodes's ID number.</li>
      </ol>
      <t>
        Addresses generated using this method will look like the following:
      </t>
      <artwork type="ascii-art" name="box.txt">
      <![CDATA[
  AAAA:AAAA:AAAA:AAAA:BBBB:BBBB:BBBB:BBBC
  |                 | |                |+- C: Node ID
  |                 | +----------------+-- B: Callsign Hash
  +-----------------+--------------------- A: Network Prefix
      ]]>
      </artwork>

      <section>
        <name>Using the Interface Identifier</name>
        <t>
          It is recommended to use the generated Interface Identifier with Stateless Address Autoconfiguration
          to automatically determine the node's IPv6 prefix and establish routes to other hosts in a radio network.
        </t>
        <t>
          While SLAAC is the recommended method of configuration, it is not required. Amateur packet radio networks 
          may also use alternate address configuration mechanisms such as DHCPv6 or manual 
          configuration as the participants see fit.
        </t>
      </section>
    
      <section>
        <name>Resolving SLAAC Duplicate Address Detection Conflicts</name>
        <t>
          As a side effect of basing the Interface Identifier on an existing globally unique identifier, 
          DAD <xref target="RFC4862"/> conflicts should be non-existent.
        </t>
        <t>
          If a conflict is encountered, the node operator SHOULD contact the operator 
          of the offending station, and/or the appropriate regulatory authority about possible 
          unauthorized use of a callsign.
        </t>
      </section>

      <section>
        <name>Benefits of this method</name>
        <t>
          This method of Interface Identifier generation has the following 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.
      </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.4291.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4862.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2460.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3315.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
        <!-- The recommended and simplest way to include a well known reference -->

      </references>

      <!-- <references>
        <name>Informative References</name>


      </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>
