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