Date: Sun, 01 Mar 2020 04:05:22 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision Message-ID: <bug-244514-227-mB3us0AoIw@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-244514-227@https.bugs.freebsd.org/bugzilla/> References: <bug-244514-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514 --- Comment #3 from ctminime@yahoo.com --- (In reply to Kristof Provost from comment #2) As far as I can tell, you are wrong about dropping packets violates RFC. I couldn't find anything of the sorts in RFC 793 or RFC 1122. What I did find, is some commentary in RFC 3360 under "The history of TCP resets". Go ahead and read it yourself. However, if you you can find that in an RFC, I would be interested to read it. I can't think of a single way that making "reply-to" RFC compliant (by default) would break any setup. It would only fix the couple of use case that it breaks. It is my personal opinion that the default behavior of a function should be RFC compliant. Then it could be up to the administrator if he chooses to violate RFC to accomplish whatever he wants. It could be done like this: "reply-to" sends all traffic, except local subnet traffic, to the gateway. (FYI, this is how pfSense behaves.) But if an administrator wanted to, for some unfathomable reason, there could be an option like "reply-to absolute" that would be specifically for violating RFC and send all traffic to the gateway. Just because this is the way it has worked for a decade+, doesn't mean it is right or should stay that way. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-244514-227-mB3us0AoIw>