This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] All-Probe Traceroute + detect RFC1918 addresses
- Previous message (by thread): [atlas] All-Probe Traceroute + detect RFC1918 addresses
- Next message (by thread): [atlas] All-Probe Traceroute + detect RFC1918 addresses
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at massar.ch
Thu Sep 16 09:28:15 CEST 2021
> On 20210915, at 21:59, Bjørn Mork <bjorn at mork.no> wrote: > > Philip Homburg <philip.homburg at ripe.net> writes: > >> As far as I know, this a well known Juniper bug where their routers >> forward errors ICMPs without checking whether the source address is >> link local. > > Thinking about this... If you can't verify the source, which with LL you cannot as they are on every interface around the world, it is spoofable. Do you really want to receive a fe80::/10 at your recursive DNS service as a request (which could be valid, locally). fe80::/10 should never have a TTL other than 1... it is link-local. The whole point of the thread is to find networks that allow non-routed addresses, the standard BCP38 trick. Detecting RFC1918 in traceroutes might just be a cheap-ish way to identify these kind of networks (especially when outbound NAT happens, thus spoofing gets killed). Greets, Jeroen
- Previous message (by thread): [atlas] All-Probe Traceroute + detect RFC1918 addresses
- Next message (by thread): [atlas] All-Probe Traceroute + detect RFC1918 addresses
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]