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

"C. M. Heard" <heard@pobox.com> Fri, 08 April 2022 23:16 UTC

Return-Path: <heard@pobox.com>
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 4FE2A3A0C94 for <tsvwg@ietfa.amsl.com>; Fri, 8 Apr 2022 16:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com
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 U3BJLtlEW0Ug for <tsvwg@ietfa.amsl.com>; Fri, 8 Apr 2022 16:16:43 -0700 (PDT)
Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72F83A0C73 for <tsvwg@ietf.org>; Fri, 8 Apr 2022 16:16:43 -0700 (PDT)
Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 9475211A04F for <tsvwg@ietf.org>; Fri, 8 Apr 2022 19:16:40 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=qzmnY4emOpwPrp+fSiu+qC23Y7VNbjaB Dhg0n+h9pHU=; b=IPMSnU/H5xiXqewiu9HWgwDhDOVguNNUMqdH3Z+/5G1JzTeh gYl4t38xyroplnp0tgqLJbzhnYdPkh3kih/8NzrIxtlDeTAwLQT2Od8Eh+8+AO/h Qbn3oR1dcl+2eZIQU7cWgM/3Eu/RUgaPPU/89chp/zaNW45SioECvM2kdkY=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 82A5511A04D for <tsvwg@ietf.org>; Fri, 8 Apr 2022 19:16:40 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-vs1-f42.google.com (unknown [209.85.217.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id BB2AC11A045 for <tsvwg@ietf.org>; Fri, 8 Apr 2022 19:16:39 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-vs1-f42.google.com with SMTP id t6so8040916vsq.11 for <tsvwg@ietf.org>; Fri, 08 Apr 2022 16:16:39 -0700 (PDT)
X-Gm-Message-State: AOAM530gYqIKSUEtxB466gAXoVkAAjrI6onRe2K9O1PXmJo1zrt8CxoG bT9yLsuh7F955hOPHhGPw9iT8RgIkOAy/DrGl2Q=
X-Google-Smtp-Source: ABdhPJyzd7R4zYhLrl5ucx9ez1D75k0TdnrOidl0LexXGemvmkkKYDzJKci7nKkvFZy+AJ983wjxGqiVPYUZ1c5XZ2s=
X-Received: by 2002:a05:6102:374c:b0:325:9c66:56fb with SMTP id u12-20020a056102374c00b003259c6656fbmr7262349vst.66.1649459798778; Fri, 08 Apr 2022 16:16:38 -0700 (PDT)
MIME-Version: 1.0
References: <20220408141318.GA32732@unix-ag.uni-kl.de> <CACL_3VGWdXziMzPzS900+-em=sc+0u1fxkH_skeBBUctJPx2XA@mail.gmail.com> <4FC16FAE-A98D-49E3-A5A1-E3959412CEA7@strayalpha.com>
In-Reply-To: <4FC16FAE-A98D-49E3-A5A1-E3959412CEA7@strayalpha.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Fri, 08 Apr 2022 16:16:27 -0700
X-Gmail-Original-Message-ID: <CACL_3VEfP4HwbnGc4i_g+wmaQXJ34H2dC10tHMs-yQfsKi-RUg@mail.gmail.com>
Message-ID: <CACL_3VEfP4HwbnGc4i_g+wmaQXJ34H2dC10tHMs-yQfsKi-RUg@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Erik Auerswald <auerswal@unix-ag.uni-kl.de>, TSVWG <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000060a59605dc2cc969"
X-Pobox-Relay-ID: F1E0867E-B791-11EC-B903-5E84C8D8090B-06080547!pb-smtp1.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/8jq4-1eE5JSTHSPQumuGwR1r9gk>
Subject: Re: [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 23:16:49 -0000

On Fri, Apr 8, 2022 at 3:42 PM Joe TOuch wrote:

>    In addition, Section 5.2.3 of [RFC4380] states:
>
>       An IPv6 packet is deemed valid if it conforms to [RFC2460]: the
>       protocol identifier should indicate an IPv6 packet and the payload
>       length should be consistent with the length of the UDP datagram in
>       which the packet is encapsulated.  In addition, the client should
>       check that the IPv6 destination address correspond [sic] to its
>       own Teredo address.
>
>
> I read that as implying UDP inside IPv6; there’s nothing in RFC2460 that
> establishes a relationship between IPv4 length and UDP length or between
> the protocol that encapsulates IPv6 (e.g., Ethernet or other link layers,
> or Teredo here) and the IPv6 length.
>
> So I’ll admit that one threw me...
>

I'll admit that I had the same reaction on a quick read ...

   This document updates the word "consistent" above 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, which are defined in the following sections.
>
>
> As the diagrams in your rationale illustrate, the IPv6 packet length
> referred to in the above paragraph is the length of the IPv6 packet
> that is ***encapsulated within*** the UDP datagram, not the payload
> length of the outer IPv4 packet. The option trailers in Teredo are
> part of the conventional UDP payload, and thus, pose no conflict
> whatsoever with the concurrent use of UDP options. On that basis,
> I agree that Teredo needs no discussion in the UDP options draft.
>
>
> I disagree; at a minimum, the kind of discussion presented here should be
> included to at least clarify that the two are compatible.
>

So maybe you are right about that. There will be no objection from me as
long as the end product says the right thing.


> But that’s a change from the current text and I’m glad if there’s
> concurrence.
>

+1

Mike