Usage of fd00::/8 on the Interwebz - something with filters and uRPF
Brian E Carpenter
brian.e.carpenter at gmail.com
Thu May 30 22:49:39 CEST 2013
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 <boogman at 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 <jeroen at 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
>
> .
>
More information about the ipv6-ops
mailing list