IETF Logo Mail Archive

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

"touch@strayalpha.com" <touch@strayalpha.com> Fri, 08 April 2022 23:42 UTC

Return-Path: <touch@strayalpha.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 579C63A0CF2 for <tsvwg@ietfa.amsl.com>; Fri, 8 Apr 2022 16:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.328
X-Spam-Level:
X-Spam-Status: No, score=-1.328 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 RhD4pZkeZPpX for <tsvwg@ietfa.amsl.com>; Fri, 8 Apr 2022 16:42:34 -0700 (PDT)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.226]) (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 CE0043A0FC0 for <tsvwg@ietf.org>; Fri, 8 Apr 2022 16:42:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9W6M2BG9sissMtvkFAvEVxYSPOWgma2bZAem6H2k9/Q=; b=HkRkoUStOqKotws5oEEgh6HpN8 lHeCtgEeLsmzTtcGIDJUczUYxXho89oUCOwbFXBqjZJ/R1FpL32g7imLnVtU6ZefmOzGZGjAXYOOz LOAMvwBP/F3Or1s/paSLb0OFlVl100rQlbu/FkJTjHAsPC/GmTz69wGhUPWhC+a0+9lbF5MxiU5Jl RW+Z/itQcgJYuwKDBkj8ZAEvL7g9vPxxaiBT2PjKw4bjV5lyM97SPjmdnTaam802I6+EIArRbXja+ 183Lvkay9efj8dhLTThVqVTE8sk2LL1QSS3RsaxchX4h5n4g3W+xDa6jU+eO4SYsUX5FSoZD+Xf4J OYy1xXHA==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:59489 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1ncyFJ-002Kz1-KF; Fri, 08 Apr 2022 19:42:34 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_CED59A46-93CE-4D99-82AE-45B9FE6BA364"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <CACL_3VEfP4HwbnGc4i_g+wmaQXJ34H2dC10tHMs-yQfsKi-RUg@mail.gmail.com>
Date: Fri, 08 Apr 2022 16:42:27 -0700
Cc: Erik Auerswald <auerswal@unix-ag.uni-kl.de>, TSVWG <tsvwg@ietf.org>
Message-Id: <0E681C1B-0CB2-4C66-BBA3-A7BE4B15B65A@strayalpha.com>
References: <20220408141318.GA32732@unix-ag.uni-kl.de> <CACL_3VGWdXziMzPzS900+-em=sc+0u1fxkH_skeBBUctJPx2XA@mail.gmail.com> <4FC16FAE-A98D-49E3-A5A1-E3959412CEA7@strayalpha.com> <CACL_3VEfP4HwbnGc4i_g+wmaQXJ34H2dC10tHMs-yQfsKi-RUg@mail.gmail.com>
To: "C. M. Heard" <heard@pobox.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Coy5JnpKYK32f1-2mXGV9H_fpGs>
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:42:40 -0000

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Apr 8, 2022, at 4:16 PM, C. M. Heard <heard@pobox.com> wrote:
> 
> 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 …

FWIW, RFC 2460 mentions UDP in only a few places. One notable one (Sec 8.1) clarifies explicitly that the pseudo header (used for UDP checkums) uses the transport length, not the IP length. So devices that do otherwise (as we’ve been talking) are in clear violation of this, if they do otherwise for IPv6 packets.

There is never a discussion of the layer in which the IPv6 packet resides. Thus I think our confusion is valid. I plan to issue an errata  to 4380 clarifying that this “conformance” isn’t specified in that RFC, and one for 6081 that clarifies it is equally irrelevant.

Unless anyone can suggest there’s a valid way to interpret the text in reference to 2460...

Joe

v2.23.0 | Report a Bug | By Email