The good thing about IPv6 is that due to the large address space it's possible to make it mandatory to encode the callsign in the last 64 bits of the address. This eliminates the problem that we have in IPv4 of trying to trace back which callsign is behind an IP.
I think it basically is a good idea, but it needs to be more flexible. We would like to be able to derive the callsign from the IP, but there should be no 1:1 mapping between callsign and IP, because that would mean only a single system can be online for each callsign.
The standard should leave some bits (at least 8) available for use as "SSID" as we had in the packet days (callsign-1 callsign-2 etc), maybe also with some encoding of alphanumeric values.
Rob
The most popular allocations from ISPs I have seen are either a /48 or a /56. Since /56 is the smallest I have found, maybe we can also use these 8-bits (bit 56 to bit 64) for a special meaning, such as the area (K4, SV2, etc.), or the country (K, SV, etc.). That way each person can have a ham subnet, and then maybe use the first bits of the remaining 64 to encode more information. This however breaks SLAAC, but assuming these will be typically servers, you can configure them statically. Now about the users I am not quite sure how it will work without resorting to solutions like stateful DHCPv6.
Antonios
On 01 Oct 2016, at 13:39, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
The good thing about IPv6 is that due to the large address space it's possible to make it mandatory to encode the callsign in the last 64 bits of the address. This eliminates the problem that we have in IPv4 of trying to trace back which callsign is behind an IP.
I think it basically is a good idea, but it needs to be more flexible. We would like to be able to derive the callsign from the IP, but there should be no 1:1 mapping between callsign and IP, because that would mean only a single system can be online for each callsign.
The standard should leave some bits (at least 8) available for use as "SSID" as we had in the packet days (callsign-1 callsign-2 etc), maybe also with some encoding of alphanumeric values.
Rob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 2016-10-01 13:45, DaKnOb wrote:
(Please trim inclusions from previous messages) _______________________________________________ The most popular allocations from ISPs I have seen are either a /48 or a /56. Since /56 is the smallest I have found, maybe we can also use these 8-bits (bit 56 to bit 64)
You are certainly an optimist. Even if general recommendations for ISPs are to allocate at least a /56 block per user, there are lots of them actually allocating dynamically only a /64 block. Even so, an encoding scheme would work...
Fortunately, there are ISPs like Hurricane Electric which offer free 6in4 tunnels for free, with /64 + /48 subnets.
Marius, YO2LOJ
Hmm.. Do you have any examples of such ISPs? I’ve only seen them give out a /64 to the PPPoE / WAN interface and then also have a routable /56 or /48 which is almost always available using DHCPv6-PD. The /64 is only used for communication with the ISP (can also be a /126) while everything else if up to the router to manage.
On 01 Oct 2016, at 15:14, Marius Petrescu marius@yo2loj.ro wrote:
You are certainly an optimist. Even if general recommendations for ISPs are to allocate at least a /56 block per user, there are lots of them actually allocating dynamically only a /64 block.
RDS-RCS, one of the biggest ISPs in Romania does this. The others don't offer IPv6...
On 2016-10-01 15:53, DaKnOb wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hmm.. Do you have any examples of such ISPs? I’ve only seen them give out a /64 to the PPPoE / WAN interface and then also have a routable /56 or /48 which is almost always available using DHCPv6-PD. The /64 is only used for communication with the ISP (can also be a /126) while everything else if up to the router to manage.
On 01 Oct 2016, at 15:14, Marius Petrescu marius@yo2loj.ro wrote:
You are certainly an optimist. Even if general recommendations for ISPs are to allocate at least a /56 block per user, there are lots of them actually allocating dynamically only a /64 block.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
El 01/10/16 a las 12:39, Rob Janssen escribió:
(Please trim inclusions from previous messages) _______________________________________________
The good thing about IPv6 is that due to the large address space it's possible to make it mandatory to encode the callsign in the last 64 bits of the address. This eliminates the problem that we have in IPv4 of trying to trace back which callsign is behind an IP.
I think it basically is a good idea, but it needs to be more flexible. We would like to be able to derive the callsign from the IP, but there should be no 1:1 mapping between callsign and IP, because that would mean only a single system can be online for each callsign.
The standard should leave some bits (at least 8) available for use as "SSID" as we had in the packet days (callsign-1 callsign-2 etc), maybe also with some encoding of alphanumeric values.
Good point, Rob.
I didn't make it clear enough in my previous message, but by "callsign" I mean "callsign + SSID". What is a valid callsign + SSID depends on which system to encode callsigns in IPv6's you use.
The system I'm using: https://github.com/darconeous/ham-addr/blob/master/ham-addr.txt.md
allows the following:
* A 8-character callsign can be encoded into an EUI-48. This can be used as a MAC for an ethernet device and SLAAC will derive the IPv6 accordingly. With a 6 character base callsign such as EA4GPZ, you can use EA4GPZ-?, where ? is any character from A to Z or 0 to 9, so you get 36 possible "callsigns + SSID". Actually, you can also encode a 9 character callsign as long as the last character is H, P, X or 5, so you can get 36*5 = 180 different "callsigns + SSID" using this ugly hack.
* An 11-character callsign can be encoded into an EUI-64. This can be used directly as the last 64bits of the IP address. With 6 character base callsign such as EA4GPZ, you can use EA4GPZ-????, so you get 36^4 possible "callsigns + SSID", which I think it's already much more than anyone will neeed. Also, you can use compound callsigns such as MW/EA4GPZ/P, should anyone have the need for this.
Other systems allow for different possibilities, but the idea is to always have some sort of SSID. One IP per callsign is not acceptable. I already have a router, a server, 2 ubiquiti devices and my laptop all running under my callsing, using different SSIDs.
73,
Dani.
-
DaKnOb -
Dani EA4GPZ -
Marius Petrescu -
Rob Janssen