From: Michal L. <ml...@lo...> - 2008-05-17 12:52:18
|
Hi Lionel, I wonder why SQLgrey 1.7.6 handles IPv6 addresses the way it does. I've performed some tests recently and it looks like the addresses are "shortened" in an overly relaxed way. For instance client address 2001:0db8:cafe:b0b0::1 is turned into bare '0db8': new: 0db8(2001:0db8:cafe:b0b0::1), a@b.xyz -> y@z.abc It doesn't care about the rest of the address: reconnect ok: 0db8(2002:0db8:cafe:b0b0::1), a@b.xyz -> y@z.abc (starts with 2002: instead of 2001: - accepted) reconnect ok: 0db8(2001:0db8:cafe:b0b0:210:ff:fe00:1), a@b.xyz ... (different host in the subnet - accepted) reconnect ok: 0db8(2001:0db8:dead:beef:260:ff:fe00:2), ... (different subnet, in real world likely a different customer - again, accepted) In some cases though it takes the whole address, e.g. for link local: fe80::260:ff:fe00:2(fe80::260:ff:fe00:2) fe80::260:ff:fe00:3(fe80::260:ff:fe00:3) or, surprisingly, my 6to4: 2002:762a:264::204:26ff:fe8b:6a9(2002:762a:264::204:26ff:fe8b:6a9) I'm not sure how the subnetting should work but am pretty sure the way it is it's not right. IMHO it should take the whole address when dealing with non-EUI64, e.g. 2001:0db8:cafe:b0b0::1 since these are probably fixed addresses of the servers, or some smaller subnets (tunnels, ADSL?), etc. where the /64 subnet might cover any number of customers. OTOH When dealing with EUI64, e.g. 2001:0db8:dead:beef:260:ff:fe00:2 it should only take the /64 subnet into account, i.e. normalize it to 2001:0db8:dead:beef::/64 since it's likely that if one server on that network segment behaves correctly the others would do as well. Anyway thanks a lot for providing IPv6 support in this great piece of software! Michal |