Maybe a possible solution for the IPv4/IPv6 verificaton in hybrid hubs supporting both ip versions that works also for IP4 or IP6 only.
A extention called, or can be called “HBRI”.
It should be capable to work for the transition IPv4 --> IPv4and6 --> IPv6
Basic hub conduct: the hub removes all the IP related info like the I, U field from the INF string and the TCP4/TCP6 SU fields that are not verified at the end of the IDENTIFY state before broadcasting the INF. (And maybe send a STA if it did)
If the hub supports more then 1 IP version and has “HBRI” support, it must
send “HBRI” in SUP during the PROTOCOL state.If client supports more
then 1 IP version and has “HBRI” he must also announce “HBRI” in his
HUB sends as normall the ISID to client.
CLIENT reponds with his INF.
If hub/client both have SU “HBRI” then
HUB sends ITCP I4"ip address" and I6"ip address" TO"token" (not sure
token is needed)
CLIENT connects to the ip its not connected with and sends HTCP SID
I6/I4"ip address" (the address he connects with) TO"token" (also for passive clients)
HUB verify’s SID, TO and if address = 0.0.0.0 or [::] it leaves/puts the
connecting ip in the SID’s I4/I6 field else the ip address is
verified en if correct left/put in the correct clients INF field
(this makes also sure NATT gets correct info)
HUB closes socket.
HUB/CLIENT communication go’s further as usual.on the intitial H-C
HUB sends STA to SID with the relevant code regarding the “HBRI”
- HUB verifies as normall (in this stage the non verified INF fields are
removed or client disconnected)
HUB can now broadcast the clients INF string.
On any change of a clients ip addresses in such a hub, the hub must verify as usual and if it’s a change regarding the non connected ip the hub must send his ITCP string again and the client should respond like in the login phase.
The the hub verify’s the info and takes action before it broadcasts the changes to the clients INF.
The above should make it possible to verify/remove all connection details who can be used for C-C connections in the hub also for passive users and gives NATT both the IP addresses it needs.
If it would be needed that a hub can use 2 different portnumbers for the IP versions this could also be included in the ITCP string that the hub sends.
A pre discusion as this forum was down can be found in the bottom of this post https://bugs.launchpad.net/adchpp/+bug/309402
Main reaso to make it a different procedure then the normall connect procedure is the fact that when you use a single procedure for other things it will always backfire sooner or later and the fact that a CID is not unique outside a hub …