Internet Engineering Task Force E. Pratten Internet-Draft 19 December 2022 Intended status: Experimental Expires: 22 June 2023 Callsign-Derived IPv6 Interface Identifiers for Amateur Radio draft-evan-amateur-radio-ipv6-02 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 June 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Pratten Expires 22 June 2023 [Page 1] Internet-Draft Callsign-Derived IPv6 Interface IDs December 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Node Addressing . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Determining the Address for a Station . . . . . . . . . . 2 2.2. Benefits of this method . . . . . . . . . . . . . . . . . 3 2.3. Drawbacks of this method . . . . . . . . . . . . . . . . 3 3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction 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. 2. Node Addressing 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. Unlike other common network protocols used by packet radio nodes, IPv6 [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. 2.1. Determining the Address for a Station To determine a 64 bit long [RFC4291] interface ID for a packet radio node, the following steps are taken: 1. Compute the SHA-256 hash of the station's UPPERCASE callsign. 2. Use the first 60 bits of the hash as the first 60 bits of the interface ID. Pratten Expires 22 June 2023 [Page 2] Internet-Draft Callsign-Derived IPv6 Interface IDs December 2022 3. Use the final 4 bits of the address' interface ID to store the station's ID. 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" [RFC4632] would result in the station address: "2001:db8::9846:807d:5b56:3a7a". 2.2. Benefits of this method This method of IP address assignment has several benefits: * 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. * Hashing callsigns instead of trying to plainly hex encode them allows support for excessively long callsigns. * 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. 2.3. Drawbacks of this method 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. 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. Pratten Expires 22 June 2023 [Page 3] Internet-Draft Callsign-Derived IPv6 Interface IDs December 2022 3. Privacy Considerations 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. The legal requirement to identify all transmissions nullifies any privacy benefits gained from other privacy-aware addressing methods such as SLAAC [RFC7217]. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations This document should not affect the security of the Internet. 6. References 6.1. Normative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . 6.2. Informative References [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . Author's Address Evan Pratten Pratten Expires 22 June 2023 [Page 4] Internet-Draft Callsign-Derived IPv6 Interface IDs December 2022 Email: evan@ewpratten.com URI: https://ewpratten.com Pratten Expires 22 June 2023 [Page 5]