Subject: [Ietf-behave] BEHAVE and SHOULD

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Mar 2005 08:17:44 -0800 (PST)

Greetings again. This last long thread on requiring NATs to process 
out-of-order fragmented TCP packets has shown a procedural problem, 
namely that folks seem to be stretching the definitions of MUST and 
SHOULD. This is bad, given that those definitions are supposed to be 
IETF-wide and stable.

At the risk of sounding too un-technical, could everyone go read RFC 
2119 again? It's surprisingly short and concise: there are two pages 
of content. See <http://www.ietf.org/rfc/rfc2119.txt>.

For those who don't want to even read two pages, a short quote should suffice:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
Given that, I have no idea why we would not say that all kinds of 
NATs SHOULD process out-of-order fragmented TCP packets correctly. 
Saying that tells implementers that they have to have some code to 
process out-of-order fragments, but their software may stop doing so 
in particular circumstances, like them running out fragment buffers.

The implications of having too few fragment buffers is that their 
NATs will cause silent and confusing damage to the data stream. If 
someone researches the problem and discovers that it is their NAT 
causing the damage, such a NAT may get poor reviews in public. Note 
that determining the number of fragment buffers is fairly easy to 
test in a lab environment.

--Paul Hoffman, Director
--VPN Consortium