[DNSOP] udp options draft

Paul Vixie <paul@redbarn.org> Thu, 13 February 2020 18:56 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D439A1201DE for <dnsop@ietfa.amsl.com>; Thu, 13 Feb 2020 10:56:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4RqMQu-Rmrw for <dnsop@ietfa.amsl.com>; Thu, 13 Feb 2020 10:56:23 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388941201CE for <dnsop@ietf.org>; Thu, 13 Feb 2020 10:56:23 -0800 (PST)
Received: from linux-9daj.localnet (dhcp-183.access.rits.tisf.net [24.104.150.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 007E2B0750 for <dnsop@ietf.org>; Thu, 13 Feb 2020 18:56:20 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Date: Thu, 13 Feb 2020 18:56:19 +0000
Message-ID: <2107892.9X7DNNYrsh@linux-9daj>
Organization: none
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pSjn_VGnJtMnPzDLw78yLYFRxYk>
Subject: [DNSOP] udp options draft
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2020 18:56:26 -0000

as most dns technologists are aware, ip and tcp have options, and udp does 
not. there is a draft:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/

which has been ongoing since 2015, which proposes to add options to udp:

Internet-Draft        Transport Options for UDP         September 2019

                             IP transport payload
                <------------------------------------------------->
      +--------+---------+----------------------+------------------+
      | IP Hdr | UDP Hdr |     UDP user data    |   surplus area   |
      +--------+---------+----------------------+------------------+
                <------------------------------>
                           UDP Length

               Figure 3 IP transport payload vs. UDP Length

this relies on the unaccounted octets which follow the udp header and data, 
inside the ip length but outside the udp length. this is moderately 
controversial since it's a deliberate layering violation, but it may be more 
workable than creating a new "udp2" ip datagram type, due to middleboxes.

the options proposed are:

Internet-Draft        Transport Options for UDP         September 2019

             Kind    Length    Meaning
             ----------------------------------------------
             0*      -         End of Options List (EOL)
             1*      -         No operation (NOP)
             2*      3         Option checksum (OCS)
             3*      6         Alternate checksum (ACS)
             4*      4         Lite (LITE)
             5*      4         Maximum segment size (MSS)
             6*      8/10      Fragmentation (FRAG)
             7       10        Timestamps (TIME)
             8       (varies)  Authentication and Encryption (AE)
             9       6         Request (REQ)
             10      6         Response (RES)
             11-126  (varies)  UNASSIGNED (assignable by IANA)
             127-253           RESERVED
             254     N(>=4)    RFC 3692-style experiments (EXP)
             255               Reserved

since dns has been the greatest single user of wide area udp, i suggest that 
those in dnsop who have an interest in this topic, please review this draft. 
something of this form will likely be created, in order to support quic, a new 
udp based transport protocol which is expected to be used by http/3.

-- 
Paul