I don't see why anyone would want to encode information about the country in the first 64 bits, especially since you can use compound callsigns such as PA/EA4GPZ if you're operating abroad.
Perhaps it would be interesting to have the information about the Maidenhead locator or GPS coordinates of a subnet (where this makes sense). Someone could use this info to make a geographical map of the network. However, I think that this info should belong to an external database (whois maybe) and not be encoded in the IPv6's.
I also don't think it should be done that way, especially because we seem to agree on the idea that we do not want to have a large IPv6 network for amprnet (which we could subnet in creative ways), but rather use the IPv6 addresses provided by a local ISP. We don't have control over the numbering and network size of those addresses, and especially during the initial phase of the rollout there will always be ISPs that do not understand IPv6 and give a customer only a single /64 or even less. Hopefully that will change later, but we cannot wait for that forever.
So, keep all special handling in the last 64 bits and treat the first 64 as random.
I think a special handling of the address should not even be mandatory, only a good suggestion that may help others to determine the source of traffic easily. It should still be possible to send traffic from addresses not conforming to this methid, at most risking that it will be dropped at an internet-radio gateway when prior arrangements have not been made.
Probably a next step would be to standardize a method to distribute information about valid IPv6 AMPRnet networks (that can be somewhat trusted in access lists).
E.g. use BGP, downloadable textfiles, (ampr-)RIPv6, etc. It may not be possible to standardize a single method due to limitations of used software and hardware, although this probably is less important than with the current gateway list. (where we need to remain compatible with very old software that cannot do IPv6 anyway)
Rob
My big question is why? I don't see any true value in this.
We ID at the RF link level.
El 02/10/16 a las 20:25, John D. Hays escribió:
(Please trim inclusions from previous messages) _______________________________________________ My big question is why? I don't see any true value in this.
We ID at the RF link level.
Perhaps someone would like to know not only what are the callsigns under which both endpoints of the RF are operating, but also who is the Amateur that originated the message and which Amateur is the final recipient. I can imagine several reasons to want to know these.
Perhaps a comparison with the DMR/D-STAR/YSF networks is in order here: not only the repeaters are properly identified, but also all the traffic is tagged with the callsign of the Amateur that originated it.
73,
Dani.
On 3/10/2016 6:42 AM, Dani EA4GPZ wrote:
Perhaps a comparison with the DMR/D-STAR/YSF networks is in order here: not only the repeaters are properly identified, but also all the traffic is tagged with the callsign of the Amateur that originated it.
Been following this discussion, but refraining from making any comments. My initial reaction was "why?", but on reading the thread and reflection, there is merit in the idea, it could be useful to know all the stations involved in an exchange, both the local RF gateways (at link level), as well as those at the IP level.
Given that there's no way of controlling what allocations ISPs give customers, I agree that the callsign needs to be encoded in the last 64 bits of the IP address, with room for a number of SSIDs. Security wise, there will need to be a simple way of identifying the properly encoded addresses, so RF gateways only pass those. Anyway, I'll keep giving this some thought. I have a /56 here that I'd like to put part of on air one day.
-
Dani EA4GPZ -
John D. Hays -
Rob Janssen -
Tony Langdon