Harlan Stenn <st...@ntp.org> wrote: > Sander Smeenk writes: >> Quoting Miroslav Lichvar (mlich...@redhat.com): >> > > > I guess it could also be a IPv6 ref mangling issue? >> > > That could well be. We use IPv6 where we can. >> > For IPv6 addresses the refid is defined as first 4 bytes of the MD5 >> > sum of the address. With 2001:7b8:3:32:213:136:0:252 (tt52.ripe.net) >> > that is 0xac023551, or 172.2.53.81 in the quad-dotted notation. >> >> Miroslav, you're right. This is it. Thanks. >> >> I consider this a bug. > > As do we all. And we can fix it as soon as a decent solution appears. > > H
For starters it could make sure the resulting "fake" address cannot be a valid IPv4 address. E.g. by fixing the high nibble to 0xf. (of course it reduces the "ID space" and increases the chances of a collision) When I understand the purpose of this field correctly, it should only hash IPv6 addresses when the server does not have an IPv4 address as well. When it does, it should use that. Else, loops could be formed involving servers that have both IPv4 and IPv6 but are not recognized as such because two different refids are generated. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
