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

ivan c <ivan@cacaoweb.org> Mon, 17 June 2013 13:14 UTC

Return-Path: <ivan@cacaoweb.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F36AB21F9BB4 for <behave@ietfa.amsl.com>; Mon, 17 Jun 2013 06:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WldIMZ1TKaRG for <behave@ietfa.amsl.com>; Mon, 17 Jun 2013 06:14:51 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org []) by ietfa.amsl.com (Postfix) with ESMTP id 96C7321F9B88 for <behave@ietf.org>; Mon, 17 Jun 2013 06:14:51 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from <ivan@cacaoweb.org>) id 1UoZHY-0005kr-2d for behave@ietf.org; Mon, 17 Jun 2013 15:15:40 +0200
To: Behave <behave@ietf.org>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_5fee2611e790f18ebe4b124d8b53fd62"
Date: Mon, 17 Jun 2013 15:15:40 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
Message-ID: <e652e4eda1b80ef8507455034552e0eb@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Subject: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ivan@cacaoweb.org
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 13:14:57 -0000

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

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. 

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_