Jan, However: in fd00:3303::1, the 3303:: could of course be a random number, but doesn't look like it. A ULA prefix should always be assigned as defined in the RFC, so whoever configured that prefix seems to have skipped a few steps.
Regards Brian Carpenter On 30/05/2013 18:50, Jan Boogman wrote: > This has been fixed now, thanks for the heads up. > > Jan > > Am 30.05.2013 um 08:27 schrieb Jan Boogman <boog...@ip-plus.net>: > >> hmm, this is the ip of our ServiceApp6 SVI interface, which C told us has >> only local significance, apparently this is not the case. >> Time to renumber then. >> >> Cheers >> Jan >> >> Am 29.05.2013 um 21:59 schrieb Jeroen Massar <jer...@massar.ch>: >> >>> ... >>> 4 2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1) 20.755 ms 20.763 ms >>> 20.784 ms >>> 5 fd00:3303::1 (fd00:3303::1) 22.010 ms 21.984 ms 21.986 ms >>> 6 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 17.806 ms 17.889 ms >>> 17.842 ms >>> 7 2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1) 18.720 ms 18.593 ms >>> 18.617 ms >>> ... >>> >>> Hmmmm fd00::/8, that really should never ever be visible on the Internet, >>> being Unique *LOCAL* Addresses. >>> And it does not look like they applied the randomness bit for picking a >>> prefix either. >>> You would also almost think that a /28 is more than enough address space to >>> put a few router loopbacks in. >>> >>> It is apparently time for people to start checking their filters again >>> because it seems that these packets leak into other ASNs too... >>> >>> More generally, do recheck your network for BCP38 compliance, please do >>> apply it and require your peers to do the same! >>> >>> Greets, >>> Jeroen > > . >