This protocol extension is used by clients for correct IPv6 usage and correct interaction with IPv4 clients when possible.
Clients use same TCP and UDP ports for both protocols. Clients can have different connection mode for IPv4 and IPv6.
Client sending in $Supports IP64 to show his support for this protocol extension.
Example:
$Supports IP64|
Client IPv4 and IPv6 support is indicated by last two bits of “magic” byte (that one after connection) in $MyINFO command.
Bit 7 (0x40) indicate IPv4 support, bit 8 (0x80) indicate IPv6 support.
Hub is responsible for enabling correct bits for all clients, even for old ones without IPv6 support.
Both bits can be enabled only when client connect to hub with IPv6, sent IPv4 in supports (see IPv4 extension for details) and hub successfully checks his IPv4 connection.
Client use those two bits to send correct IP in $ConnectToMe. IPv6 can be only send to clients supporting IPv6. To others and to older clients is always send IPv4.
That way is compatibility with older clients maintained, and new things sent only to clients supporting them.
Hub is responsible for checking if client sent his real IP and should check if IPv6 IP is sent to IPv6 client and IPv4 to IPv4 client.
For IPv6 addreses is used standard format for literal IPv6 addresses [IPv6_address]:port (ie [::1]:1209) as it is defined in RFC 3986.
Examples:
IPv6 search $Search [::1]:1234 F?T?0?1?test|
IPv6 connection request $ConnectToMe PPK [::1]:1234|
Because client on IPv6 can have different connection mode than in IPv4 we have extended mode in tag.
M: now have two chars, first for mode in IPv4 and second for mode in IPv6. When client don't support IPv4 or IPv4 check by hub failed then first char can be N (Not supported/available).
Example:
Client with pasive IPv4 and active IPv6: $MyINFO $ALL PPK this is a test <Cz V:0.800,M:PA,H:1/0/10,S:3>$ $Cable;$$0$|
Client without IPv4 with pasive IPv6: $MyINFO $ALL PPK this is a test <Cz V:0.800,M:NP,H:1/0/10,S:3>$ $Cable;$$0$|
Sending two search commands (one with IPv6 address and one with IPv4 address) will be simply stupid.
So client connected to hub with IPv6 is sending only one search request.
When client is active in one of TCP/IP protocols then he should always send active search request.
Hub will send this request only to clients with same TCP/IP protocol that was used in original search request and create correct request for second TCP/IP protocol (again is sent only to clients supporting that TCP/IP).
In case when client sent passive search request then it is sent only to active users supporting same TCP/IP protocol(s) as sender. Second request is not created even when client is active in one TCP/IP, because hub don't know client UDP port for active search.