[tsvwg] Teredo Extensions vs. draft-ietf-tsvwg-udp-options-18

Erik Auerswald <auerswal@unix-ag.uni-kl.de> Fri, 08 April 2022 14:13 UTC

Return-Path: <auerswal@unix-ag.uni-kl.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344FB3A05F8 for <tsvwg@ietfa.amsl.com>; Fri, 8 Apr 2022 07:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 YetCmPJbjw4Z for <tsvwg@ietfa.amsl.com>; Fri, 8 Apr 2022 07:13:23 -0700 (PDT)
Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976BB3A0597 for <tsvwg@ietf.org>; Fri, 8 Apr 2022 07:13:22 -0700 (PDT)
Received: from sushi.unix-ag.uni-kl.de (sushi.unix-ag.uni-kl.de [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 238EDIY8048656 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Fri, 8 Apr 2022 16:13:18 +0200
Received: from sushi.unix-ag.uni-kl.de (ip6-localhost [IPv6:::1]) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 238EDIXT000727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Apr 2022 16:13:18 +0200
Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 238EDINK000726; Fri, 8 Apr 2022 16:13:18 +0200
Date: Fri, 08 Apr 2022 16:13:18 +0200
From: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
To: TSVWG <tsvwg@ietf.org>
Message-ID: <20220408141318.GA32732@unix-ag.uni-kl.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Author: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/AunBhrD-qDfSWhJ3IVSRAFmndlI>
Subject: [tsvwg] Teredo Extensions vs. draft-ietf-tsvwg-udp-options-18
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2022 14:13:27 -0000

Hello tsvwg,

draft-ietf-tsvwg-udp-options-18 mentions possible interactions of
UDP Options with Teredo Extensions (RFC 6081) in section 20:

    """
    As a result, UDP options are not compatible with TE, but that is
    also why this document does not update TE. Additionally, it is not
    at all clear how TE operates[.]
    """

>From looking at both the Teredo RFC 4380 and the Teredo Extensions
RFC 6081 I would say that Teredo Extensions seem to be compatible
with the proposed UDP Options.

Therefore, I would suggest to remove every paragraph pertaining to
Teredo Extensions and the informative references to RFC 4380 and
RFC 6081 from draft-ietf-tsvwg-udp-options.

Alternatively, they could be replaced by a short paragraph mentioning
the similarity of ideas, keeping the informative reference to RFC 6081.


Rationale
---------

Teredeo Extensions use an idea similar to UDP Options: combining the
information provided by different length fields allows to infer use
of additional data between the end of the original ("legacy", i.e.,
before adding an extension or option trailer) payload and the end of
an outer protocol data unit.

Teredo Extensions use the difference between the UDP length of the
outer IPv4/UDP datagram and the length of the IPv6 packet encapsulated
inside this UDP datagram.  This relies on all parts of the Teredo
payload having either a known length or a length field.

This is the basis for redefining the word "consistent" as used in
RFC 4380 in RFC 6081 section 4 as follows:

    """
    The IPv6 payload length is "consistent" with the length of the UDP
    datagram if the IPv6 packet length (i.e., the Payload Length value
    in the IPv6 header plus the IPv6 header size) is less than or equal
    to the UDP payload length (i.e., the Length value in the UDP header
    minus the UDP header size).  This allows the use of trailers after
    the IPv6 packet[.]
    """

I.e., RFC 6081 explicitely allows the outer UDP datagram to extend
past the encapsulated IPv6 packet which is part of the UDP payload.

I think that the following illustrations correctly describe Teredo
packets and show why I am of the opinion that UDP Options are in
principle compatible with Teredo and Teredo Extensions.


RFC 4380 Teredo Packet without Teredo Extensions
------------------------------------------------

+--------+--------+----------+--------------+
| IPv4   | UDP    | Teredo   | encapsulated |
| header | header | options  | IPv6 packet  |
+--------+--------+----------+--------------+
                              <--IPv6 len-->
          <------------UDP length---------->
 <---------------IPv4 length--------------->

The IPv4 header contains length fields that provide the length of the
whole packet.  The UDP header contains a length field that provides
the length of the UDP datagram.  The Teredo options are either of fixed
length or contain length fields.  The encapsulated IPv6 packet contains
length fields that provide the whole length.

With neither Teredo Extensions nor UDP Options, the end of the
encapsulated IPv6 packet, the end of the UDP datagram, and the end of
the outer IPv4 packet coincide.

[Note: Teredo options can be omitted ("simple encapsulation").]


RFC 6081 Teredo Packet with Teredo Extensions
---------------------------------------------

With Teredo Extensions, the end of the encapsulated IPv6 packet no longer
coincides with the end of the UDP datagram and the outer IPv4 packet.
The end of the UDP datagram and the outer IPv4 packet still coincide.

+--------+--------+----------+--------------+-------------+
| IPv4   | UDP    | Teredo   | encapsulated | Teredo      |
| header | header | options  | IPv6 packet  | Extensions  |
+--------+--------+----------+--------------+-------------+
                              <--IPv6 len-->
          <--------------------UDP length---------------->
 <----------------------IPv4 length---------------------->


Teredo Packet with Teredo Extensions and UDP Options
----------------------------------------------------

With UDP Options as per draft-ietf-tsvwg-udp-options-18, the end of the
UDP datagram and the outer IPv4 packet no longer coincide.

+--------+--------+----------+--------------+-------------+---------+
| IPv4   | UDP    | Teredo   | encapsulated | opt. Teredo | UDP     |
| header | header | options  | IPv6 packet  | Extensions  | options |
+--------+--------+----------+--------------+-------------+---------+
                              <--IPv6 len-->
          <--------------------UDP length---------------->
 <---------------------------IPv4 length--------------------------->

This should work as well as with most other UDP based protocols.

Best regards,
Erik