IPv6 prefix /64 is zero

1

Dear all,

Looking at “mrulist” I see some IP V6 addresses like this:

   226    440  1d0 . 3 3      2 51311 ::1470:16ff:fe72:1564
   231   1228  1d0 . 3 3      9 42402 ::e085:b8ff:fe9c:d270
   231    438  1d0 . 3 3      2 33027 ::1c3c:7ff:fe9c:ae40
   241    435  1d0 . 3 3      2 47910 ::7407:6eff:fece:87df
   254    437  1d0 . 3 3      2 49743 ::104c:9aff:fe9c:5d55
   260   1097  1d0 . 3 3     10 36836 ::60b3:92ff:fe05:5a23
   265    395  1d0 . 3 3      2 45753 ::d4de:87ff:fef7:c0a2

These are about 0.3% of all IPv6 addresses which have in the network part all zero. I am not new to IPv6 but haven’t seen this before. How is it possible that the network part is 0 ? Knowing not possible to know everything I googled around a little bit but couldn’t find any useful information. I am using ntp-4.2.8p10. Is this maybe a bug of NTP or is it a try to break something ? Maybe it has a real background.

Has anybody else seen this at his public NTP server.

Any information would be nice.

Kind regards
Hans

–

2

Yes – I also see these type of V6 addresses. The response packets certainly wont go anywhere useful! It appears that I get about 20 of these per day.

Most of them are the EUI64 form (i.e. they are generated from the MAC address). However, the mac addresses are not clumped (so it seems unlikely that they are all from a single poor client implementation).

This is a chunk of mine from the last couple of days:

::1034:56FF:FE78:2
::1CE6:50FF:FE1B:3FC1
::1CE9:A6FF:FE7B:A170
::200:FF:FE00:0
::3498:50FF:FE7F:8542
::3881:91FF:FEC6:AEF4
::445C:B5FF:FEDE:4EDC
::4910:4EE4:CEA4:AF9A
::4C4F:82FF:FE12:DA2E
::5041:23FF:FE67:7886
::51BC:FBFC:56FB:6B73
::54A7:EFF:FEFA:48B1
::54F1:CFF:FEB6:8C3C
::58E7:8FFA:9B09:9028
::5C4F:A7FF:FE05:987B
::7004:6AFF:FE41:CD35
::79E4:7EE0:2115:1BCE
::8068:A7C0:8000:9406
::8068:A7C0:8000:9409
::8070:E14:8000:9401
::8070:E14:8000:9402
::8070:E14:8000:940A
::80CF:8FF:FEEE:3DFA
::865:352E:28C0:1D2A
::89E7:14A4:3276:2AC4
::8CB9:F5B5:8B35:E56F
::9082:66FF:FEB8:8199

Oh – I’m running entirely custom NTP server code, so it is very unlikely to be a server side implementation bug.

3

I see those packets, too.
Based on the Hoplimit field of these packets, they seem to be originating somewhere in europe.