Subject: cancel-tcpip-forward matching

From: der Mouse <[email-masked]>
Date: Fri, 9 Apr 2004 23:18:01 -0400 (EDT)

When doing a cancel-tcpip-forward, how exactly does the request have to
match the tcpip-forward request it's cancelling?

For example, if I send a tcpip-forward request specifying the peer
machine by name, can I cancel it specifying the peer machine by
address?  (To be concrete, say I tcpip-forward
"sparkle-4.rodents.montreal.qc.ca" port 12345, can I cancel it by
cancel-tcpip-forwarding "216.46.5.7" port 12345?)

If a tcpip-forward request implies binding multiple address/port pairs,
is it possible to cancel some but not all of them by specifying them by
address (or more-specific name)?  As a concrete example, suppose I
tcpip-forward "sparkle.rodents.montreal.qc.ca" port 12345 (implying
both 216.46.5.7/12345 and 3ffe:b00:4020:300::7:0/12345); can I then
cancel-tcpip-forward "3ffe:b00:4020:300::7:0" port 12345 and still
leave the 216.46.5.7/12345 forwarding active?

Or is all this left up to the implementations?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Markus Friedl <[email-masked]>
Date: Sat, 10 Apr 2004 16:53:59 +0200

> Or is all this left up to the implementations?

i would only cancel on exact string matches.  but this is left up
to the implementation.

---

From: "denis bider" <[email-masked]>
Date: Tue, 13 Apr 2004 11:39:41 +0200

> i would only cancel on exact string matches.  but this is left up

I don't think it's so much up to the implementation... I think this is
the Correct Way. The idea being - what you effect with one request, you
can cancel with a symmetric one, without having to understand the
implementation semantics.

I.e., regardless of the values of "listen address" and "listen port",
these form the name and unique identifier of a request, and any side
effects of the request are canceled by supplying the original request's
unique identifier, which is the "listen address" and "listen port" as
supplied previously.

I think an implementation that did not adopt this idea would be
broken... The whole idea of standards is to get consistent output when
supplying consistent input.

---

From: der Mouse <[email-masked]>
Date: Tue, 13 Apr 2004 06:02:33 -0400 (EDT)

>> i would only cancel on exact string matches.  but this is left up to
>> the implementation.
> I don't think it's so much up to the implementation... I think this
> is the Correct Way.  The idea being - what you effect with one
> request, you can cancel with a symmetric one, without having to
> understand the implementation semantics.

Yes; I agree that if the same string is given, the preceding request
should be undone.

My question really bears more on what happens when a different string
is given.  _Must_ the server reject the cancel attempt, or is it
permitted to possibly cancel previous requests, or portions of previous
requests, that match the cancel request it in an implementation-defined
way?

> broken... The whole idea of standards is to get consistent output
> when supplying consistent input.

For what it may be worth, my implementation as it stands does not quite
do this.  For numeric and wildcard forwarding, I think it does - but if
the host string is a FQDN, and the set of addresses it resolves to at
cancel time is not the same as the set of addresses it resolves to at
request time, the cancel may not cancel exactly and only the
forwardings established by the forward request.

I'm not sure whether I consider this behaviour broken.  After all,
telnet and the DNS are standardized too, and yet nobody thinks it
broken that "telnet foo.example.net" may connect you to two different
hosts at different times if the DNS has changed in between.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign