On 2/27/23 1:13 AM, Rolf Winter wrote:
But feedback from the operational community on this would be
valuable. Our reverse traceroute currently restricts the server to
trace back to the issuing client. We did this for security reasons.
I understand the motivation for your team's caution
On Mon, 27 Feb 2023 at 10:16, Rolf Winter wrote:
> "https://downforeveryoneorjustme.com/;. But, somebody might use your
> server for this. How do people feel about this? Restrict the reverse
> traceroute operation to be done back to the source or allow it more
> freely to g
That means, in fact (if you have credits) you can already
reverse traceroute from an Atlas Probe to yourself (and other places on
the internet).
But, you are raising in interesting point, which we have thought about
but dismissed. But feedback from the operational community on this would
be val
Before "revtr-lg" sticks, in the grand tradition of Paris Traceroute and
Tokyo Ping we call our version of traceroute "Augsburg Traceroute". And
it does not resemble a looking glass server. There are two parties
involved in a reverse traceroute operation (not counting the
Chris, thanks for mentioning me/our project! Rolf, thanks for pointing to our
recent 2nd reverse traceroute paper
<https://hal.science/hal-03788618v1/file/internet-scale-revtr.pdf>!
Our recent paper addressed what we saw as the major limitations of my
original 1st reverse traceroute paper
On 2/25/23 3:09 AM, Tore Anderson wrote:
I suggest you get in touch with the fine folks at NLNOG RING and ask it
they would be interested in setting this up on the 600+ RING nodes all
over the world. See https://ring.nlnog.net/.
Similarly you might reach out to RIPE and inquire if they are
the traceroute operation to us for further analysis.
Additionally, the endpoint "playground.net" is currently used for
some variations of reverse traceroute, so some measurements might not
work currently. You can just use any of the other endpoints.
Best,
Rolf
Am 25.02.23 um 11:
* Rolf Winter
> If you would like to play with reverse traceroute, the easiest option
> is to work with the client and use one of the public server instances
> (https://github.com/HSAnet/reverse-traceroute/blob/main/ENDPOINTS).
> If you would be willing to host a public server insta
://revtr.ccs.neu.edu/
That piece of work and ours differ in a number of ways. Whereas the work
you cite is an external system really, that let's you perform a reverse
traceroute through said system, we have implemented something, that
works just like traceroute does today, but for the reverse direction
iven that paths through the public internet are usually
> asymmetric, knowing the reverse path would be beneficial e.g. for
> troubleshooting purposes (https://youtu.be/L0RUI5kHzEQ?t=2312).
>
> We have implemented a reverse traceroute tool
> (https://github.com/hsanet/reverse-trace
implemented a reverse traceroute tool
(https://github.com/hsanet/reverse-traceroute), both client and server
for both IPv4 and IPv6. We are also in the process of specifying the
protocol at the IETF
(https://datatracker.ietf.org/doc/html/draft-heiwin-intarea-reverse-traceroute).
We also gave
http://revtr.cs.washington.edu/
I was also looking for a such a kind of tool some days ago.
--
Tassos
Ryan Shea wrote on 10/09/2010 00:35:
According to the presentation they were planning on releasing a
downloadable tool by May 2009, but in searching around I found no
evidence that this was
I missed this meeting/preso when it happened (yes, 5+ meetings ago)
http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTE4OCZuYW5vZzQ1nm=nanog45
I note the talks about using spoofed source packets to do some
measurement, I didn't see anyone in the video say: But spoofing is
bad, but you
According to the presentation they were planning on releasing a
downloadable tool by May 2009, but in searching around I found no
evidence that this was ever released.
-Ryan
On Thu, Sep 9, 2010 at 4:22 PM, Christopher Morrow
christopher.mor...@gmail.com wrote:
I missed this meeting/preso when
14 matches
Mail list logo
