Internet Engineering Task Force E. Pratten Internet-Draft 16 February 2023 Intended status: Experimental Expires: 20 August 2023 A Method for Deriving Stable IPv6 Interface Identifiers from Amateur Radio Callsigns draft-evan-amateur-radio-ipv6-04 Abstract 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 an amateur radio node's government-assigned callsign as the basis for its Interface Identifier. 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 20 August 2023. Copyright Notice Copyright (c) 2023 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 Pratten Expires 20 August 2023 [Page 1] Internet-Draft Callsign-Derived IPv6 IIDs February 2023 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Foreword on Node Identification . . . . . . . . . . . . . . . 3 4. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Direct Encoding Charset . . . . . . . . . . . . . . . . . 4 4.2. An Example Implementation . . . . . . . . . . . . . . . . 4 4.3. Using the Interface Identifier . . . . . . . . . . . . . 5 4.4. Resolving SLAAC Duplicate Address Detection Conflicts . . 6 4.5. Benefits of this method . . . . . . . . . . . . . . . . . 6 4.6. Drawbacks of this method . . . . . . . . . . . . . . . . 7 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction This document specifies the steps an amateur packet radio node takes in order to generate a stable and unique IPv6 Interface Identifier (IID) [RFC2460]. The resulting Interface Identifier SHALL be used in conjunction with processes such as (but not limited to) Stateless Address Autoconfiguration (SLAAC) [RFC4862], DHCPv6 [RFC3315], or manual configuration to configure IPv6 connectivity on the node. 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. 2. Terminology 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 [RFC2119]. Pratten Expires 20 August 2023 [Page 2] Internet-Draft Callsign-Derived IPv6 IIDs February 2023 3. Foreword on Node Identification Amateur packet radio nodes generally identify themselves with a string of ASCII characters comprised of: 1. The station's government-assigned callsign 2. A dash (-) 3. 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. For example, a node operated under the callsign "VA3ZZA" with the node ID of "5" would identify itself on-air as "VA3ZZA-5". 4. The Algorithm To determine a 64 bit long [RFC4291] Interface Identifier for an amateur packet radio node in conformance with this specification, the following steps MUST be be taken: 1. Set the lest significant 4 bits of the Interface Identifier to the node's ID number. 2. If the callsign is less than or equal to 9 characters in length: 1. Set the most significant bit of the Interface Identifier (the hash bit) to 0. This indicates that "Direct Encoding" is in use. 2. Using the "Direct Encoding Charset" defined below, pack the UPPERCASE callsign into the middle 59 bits of the Interface Identifier. Callsigns shorter than 9 characters must be right-padded with spaces. This means that the callsign "VA3ZZA" would be encoded as "VA3ZZA " (3 trailing spaces). 3. If the callsign is greater than 9 characters in length: 1. Set the most significant bit of the Interface Identifier (the hash bit) to 1. This indicates that hashing is in use. 2. SHA-256 hash the callsign 3. Bitwise AND the hash with the 64 bit value 0x7FFFFFFFFFFFFFF0 4. Bitwise OR the result to the Interface Identifier Pratten Expires 20 August 2023 [Page 3] Internet-Draft Callsign-Derived IPv6 IIDs February 2023 Addresses generated using this method will look like the following: AAAA:AAAA:AAAA:AAAA:BCCC:CCCC:CCCC:CCCD | | || || | | || |+- Node ID | | |+---------------+-- Callsign or Hash | | +------------------- Hash Bit + Callsign or Hash +-----------------+--------------------- Prefix 4.1. Direct Encoding Charset When directly packing a shorter callsign into the Interface Identifier, the following charset MUST be used: - 000000 S - 010011 A - 000001 T - 010100 B - 000010 U - 010101 C - 000011 V - 010110 D - 000100 W - 010111 E - 000101 X - 011000 F - 000110 Y - 011001 G - 000111 Z - 011010 H - 001000 0 - 011011 I - 001001 1 - 011100 J - 001010 2 - 011101 K - 001011 3 - 011110 L - 001100 4 - 011111 M - 001101 5 - 100000 N - 001110 6 - 100001 O - 001111 7 - 100010 P - 010000 8 - 100011 Q - 010001 9 - 100100 R - 010010 / - 100101 Each character translates to 6 bits. This allows for more efficient packing of longer callsigns. 4.2. An Example Implementation Pratten Expires 20 August 2023 [Page 4] Internet-Draft Callsign-Derived IPv6 IIDs February 2023 import hashlib CHARSET = " ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789/" def encode(callsign: str, node_id: int = 0) -> int: # The output is a 64-bit integer output = 0x0000000000000000 # The right-most 4 bits are the node ID output |= node_id & 0x0F # If the callsign is longer than 9 characters, # perform a hash operation if len(callsign) > 9: # Set the hash bit output |= 0x8000000000000000 # Hash the callsign hashed = hashlib.sha256(callsign.encode("ascii")).digest() # Truncate the hash to 59 bits output |= int.from_bytes(hashed, "big") & 0x7FFFFFFFFFFFFFF0 else: # Text-transform and right-pad the callsign # with spaces as needed callsign = callsign.upper().ljust(9, " ") # Fill in the remaining bits via the charset. # The leftmost callsign character will be the # leftmost 6 bits of the output for i in range(9): six_bits = CHARSET.index(callsign[i]) & 0x3F output |= six_bits << (58 - (i * 6)) return output 4.3. Using the Interface Identifier 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. Pratten Expires 20 August 2023 [Page 5] Internet-Draft Callsign-Derived IPv6 IIDs February 2023 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. 4.4. Resolving SLAAC Duplicate Address Detection Conflicts As a side effect of basing the Interface Identifier on an existing globally unique identifier, DAD [RFC4862] conflicts should be non- existent for permanent callsigns. If a conflict is encountered when using a permanent callsign, the node operator SHOULD contact the operator of the offending station, and/or the appropriate regulatory authority about possible unauthorized use of a callsign. Due to the need for hashing of longer temporary callsigns, a hash collision may occur. If this happens, the node operator SHOULD append a suffix to the node's callsign. Callsign suffixes are arbitrary strings that start with "/" and contain characters A-Z and 0-9. For example, adding a suffix of "IETF" to "VA3ZZA" could result in a callsign like "VA3ZZA/IETF". 4.5. Benefits of this method This method of Interface Identifier generation has the following benefits: * Callsigns are uniquely assigned to stations by existing governing bodies. Using them as the basis of address creation will ensure a unique seed or basis for the Interface Identifier. * Hashing long callsigns instead of trying to directly encode them allows support for excessively long temporary 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. * Stations operating with permanent callsigns will have the benefit of their callsign being automatically transmitted with every packet (encoded in the source address), in a format that satisfies many governments' station identification requirements. Pratten Expires 20 August 2023 [Page 6] Internet-Draft Callsign-Derived IPv6 IIDs February 2023 4.6. Drawbacks of this method * Stations operating with excessively long temporary callsigns will need to separately identify their transmissions as their callsign will not be transmitted by default with each packet. * Stations operating with excessively long temporary callsigns may encounter hash collisions with other stations (although extremely unlikely). In the event of this happening, the node operator will be required to perform additional reconfiguration of their node. 5. 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. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations This document should not affect the security of the Internet. 8. References 8.1. Normative References [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . Pratten Expires 20 August 2023 [Page 7] Internet-Draft Callsign-Derived IPv6 IIDs February 2023 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Author's Address Evan Pratten Email: evan@ewpratten.com URI: https://ewpratten.com Pratten Expires 20 August 2023 [Page 8]