Comment 39 for bug 309402

(1) I share Big Muscle's concern. This proposed HBRI extension addresses the client-hub aspect, but the client-client issues remain. This does, as Pirre has elsewhere pointed out, form a necessary condition for client-client connections.

In some circumstances, this is an insurmountable problem - if a pair of users cannot share an IP protocol, but such should be rare given the coming near-ubiquity not of pure IPv6 users, but of of dual-stacking. Therefore I suspect BM's worst-case will not become common.

(2) It's a little odd the client sends its own email address at all, but that's not a quirk new to HBRI and does render it consistent with DC++'s current behavior. The default address a client would send to a hub is 0.0.0.0 (or, one would suppose, :: for IPv6) regardless. I'm just unsure under what circumstances allowing meaningfully different client-sent IPs makes sense.

(3) Otherwise, HBRI seems to function reasonably and with about as few round-trips as one can get away with. I like that it doesn't place additional constraints on which of the four combinations of (IPv4 yes/no) and (IPv6 yes/no) that a given client might be able to listen on due to ISP routing, firewalling, or NAT considerations.

Having a dual-stack hub (or effective hub, if one splits roles across machines or software, but that doesn't affect the protocol suggested) seems a minimal requirement for any solution to this, such that the hub can verify both IPv4 and IPv6 addresses. HBRI seems a near-minimal yet usable extension of ADC to allow that and as such it seems worthwhile.