https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514
--- Comment #3 from [email protected] --- (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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
