Hi Philip, On Wed, Nov 6, 2013 at 12:01 PM, Philip Homburg <philip.homburg@ripe.net> wrote:
There are various reasons why RIPE Atlas cannot provide an interface that allows the user to specify arbitrary packets going out and reporting everything that is received. The first one is a security issue and the second leads to storage problems on the older probes. For this reason it would be nice if feature requests can be both minimal and specific. I.e. what is the minimal amount of reporting you need to measure what you want to measure and what is a safe way to generate the packets you need.
Sure, we can work on more detailed feature request indeed if we agree with the idea of extension header support in principle. Regarding the storage problem on the old probes: as it's being discussed, it might be a good idea to allow probe owners to opt-in for 'risky' UDMs so old probes could be excluded.
In this context, would it be sufficient to have hop-by-hop or destination options that just consist of pad options? Hopefully somebody from the operator community can guess whether unlimited use of hop-by-hop options filled with padding would be safe.
I'd say that using hop-by-hop header is potentially more risky than destination/fragmentation headers. IMHO the priority list looks like: - destination and fragment headers (with pad1/padN support for destination option); - hop-by-hop header - but we might need to consider how to minimize the risk.
(By the way, I have no idea how routers are supposed to support hop-by-hop options for unicast packets. Does that do anything useful other than trying to DoS the router?)
Off top of my head: RSVP. In addition, there are some other possible use cases being discussed currently.
Finally, RIPE Atlas is not a mesh network. A subset is (the Atlas Anchors, but that part is very small at the moment). So using Atlas gives you more sources of traffic, but not more destinations.
Even getting more sources is very useful indeed.. -- SY, Jen Linkova aka Furry