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/mat-wg@ripe.net/
[mat-wg] IPv6 extension headers support on RIPE Atlas
- Previous message (by thread): [mat-wg] IPv6 extension headers support on RIPE Atlas
- Next message (by thread): [mat-wg] IPv6 extension headers support on RIPE Atlas
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jen Linkova
furry13 at gmail.com
Thu Nov 7 15:42:07 CET 2013
Hi Philip, On Wed, Nov 6, 2013 at 12:01 PM, Philip Homburg <philip.homburg at 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
- Previous message (by thread): [mat-wg] IPv6 extension headers support on RIPE Atlas
- Next message (by thread): [mat-wg] IPv6 extension headers support on RIPE Atlas
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ mat-wg Archives ]