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 ]
Bjørn Mork
bjorn at mork.no
Fri Sep 17 21:20:19 CEST 2021
Gert Doering <gert at space.net> writes: > "What happens inside your network happens inside your network" (and > the RFC explicitly permits that, of course), but we do not want to > see it on someone else's network. Exactly my point. My traceroute example is all in "my" network if you include the mobile access endpoint. The usage of RFC1918 for PGW pools and links is co-ordinated. There is no reason you should not see RFC1918 adresses as source here. >> > Given the age of the document, the language used to be less STRONG >> > back then. >> >> Sure. Assigning RFC1918 addresses to customers was also unheard of, and >> didn't even need to be mentioned. > > If that is CGN'ed, it's not violating the RFC. Of course it's not. But you'll have to define the customer endpoint as part of the RFC1918 "enterprise" network. > Leaking packets from addresse that do not belong to you does. Yes. And the point is that you cannot tell if there is a leakage unless you are able to detect the network borders. Which you can't by counting traceroute hops. Bjørn
- 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 ]