[BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago

[ivan c <[e-mail]>]

Speaking of this, reading draft-penno-behave-rfc4787-5382-5508-bis
reminded me of a conversation I had many years ago with the Editor of
RFC5382. 

Back then, it was acknowledged that the most desirable behavior
for a NAT to support TCP simultaneous open between 2 peers behind NATs was
to have TCP port preservation. REQ 1 is a weaker condition that can be used
by NAT that do not implement port preservation, but can use a third party
server to perform port prediction. The Editor said at the time that this
would be updated in the next version of RFC5382, but I actually haven't
heard of him since then as he seems to have vanished off the group a long
time ago. 

REQ 7 was supposed to be fixed too, as the condition it
requires is way too strong as everyone can see. Port overloading for TCP is
perfectly acceptable when the remote endpoints are distinct. With large
scale deployments of CGNs, it has now become a desirable behavior.


Another point, as far as I'm aware, no peer to peer application
implements the SO_REUSEADDR hack that RFC5382 advocates to perform TCP
simultaneous open. Again, TCP port preservation is generally used as there
is more support for this scheme in NAT deployments in the wild. Use of the
SO_REUSEADDR hack violates RFC793 and should be used with extra care. 

If
NAT implementers are really reading this RFC as it is, this is going to be
the source of much confusion. 

I'm not sure whether the correct thing to
do would be to write an Errata for these points or simply to write a new
RFC based on the new work of draft-penno-behave-rfc4787-5382-5508-bis .


Please don't hesitate to ask me for technical clarifications, as these
discussions happened many years ago and some of the context might have been
lost by the current participants. 

-- 
_Ivan Chollet_