Re: [HAM-AG] [IPv6] Request for feedback: draft-evan-amateur-radio-ipv6

[Warren Kumari <[e-mail]>]

On Wed, Feb 15, 2023 at 7:33 PM, Nick Harper <[e-mail]> wrote:

> I had to look up that ITU regulation, so I don't know if there's a max
> length on temporary callsigns.
>
> If you treat the callsign as a base-36 number, you could squeeze up to 11
> characters into 60 bits.
>


To me, this seems like a best option — hashing the call-sign feels somewhat
like a "you are so sharp you’ll cut yourself" situation. Yes, it takes the
call-sign space and spreads it out, and yes, it gives some sort of illusion
of "privacy", but it adds significant complexity and  raises the collisions
issue.

It also seems much cleaner that AC4WK/1, AC4WK/7, AC4WK/P and AC4WK/M all
cluster together.


> If you really want to handle callsigns of arbitrary length, you could use
> some of the 60-bit space for direct encodings of short (e.g. <=7
> characters) callsigns and the rest of the space for the hash of longer
> callsigns.
>
> On Wed, Feb 15, 2023 at 4:13 PM Evan Pratten <[e-mail]> wrote:
>
>> I have personally held temporary callsigns longer than 7 characters,
>> which is why I wanted to handle that.
>
>
When you say "longer than 7 characters", what do you mean? 8 characters? 9?
10?

73,
  AC4WK.




>> Using a more space efficient encoding scheme is an interesting idea.
>> Do you know if there is a maximum length on temporary callsigns by
>> chance?
>>
>> I'll think about doing away with the hash in favor of space-efficient
>> encoding.
>>
>> On Wed, Feb 15, 2023 at 7:10 PM Nick Harper <[e-mail]> wrote:
>> >
>> > Why hash the callsign at all?
>> >
>> > Article 19 of ITU's Radio Regulations specifies the format of
>> callsigns, and they are at most 7 characters long. The ASCII representation
>> of the callsign could be used to generate 7 bytes (56 bits) to use in the
>> address without needing any hashing. For the exception in 19.68A (on
>> special occasions, for temporary use, callsigns could be longer than 7
>> characters), a 6-bit encoding scheme could be devised so that alphanumeric
>> callsigns up to 10 characters long could be encoded in 60 bits.
>> >
>> > On Wed, Feb 15, 2023 at 3:28 PM Donald Eastlake <[e-mail]>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Wed, Feb 15, 2023 at 3:03 PM Evan Pratten <[e-mail]>
>> wrote:
>> >> >
>> >> > On Wed, Feb 15, 2023 at 2:58 PM Donald Eastlake <[e-mail]>
>> wrote:
>> >> > > I'm not sure the hash even needs to be cryptographic.
>> >> >
>> >> > Agreed. I would call a cryptographic hash *undesierable*. Why waste
>> >> > processing power hiding the callsign when you have to ID yourself
>> >> > anyways?
>> >> >
>> >> > I am admittedly far from an expert on hashing algorithms. Donald, do
>> >> > you have any suggestions that fit the properties you outlined by
>> >> > chance?
>> >>
>> >> Indeed, I would suggest using FNV-64 truncated to the top 60 bits, See
>> >> https://datatracker.ietf.org/doc/draft-eastlake-fnv/
>> >>
>> >> Here is an article on using FNV-32 for IPv6 flow label
>> >> https://researchspace.auckland.ac.nz/bitstream/handle/2292/13240/
>> flowhashRep.pdf
>> >>
>> >> Thanks,
>> >> Donald
>> >> =============================
>> >>  Donald E. Eastlake 3rd   [phone] (cell)
>> >>  2386 Panoramic Circle, Apopka, FL 32703 USA
>> >>  [e-mail]
>> >>
>> >> --
>> >> HAM-AG mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ham-ag
>>
> -------------------------------------------------------------------- IETF
> IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>