IETF Logo Mail Archive

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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 09 April 2022 08:00 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 96BE93A21E2 for <tsvwg@ietfa.amsl.com>; Sat, 9 Apr 2022 01:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-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
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 B_v3eenV0Xow for <tsvwg@ietfa.amsl.com>; Sat, 9 Apr 2022 01:00:36 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id B430F3A21E1 for <tsvwg@ietf.org>; Sat, 9 Apr 2022 01:00:36 -0700 (PDT)
Received: from [192.168.1.64] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 16A2D1B001AD; Sat, 9 Apr 2022 09:00:23 +0100 (BST)
Content-Type: multipart/alternative; boundary="------------SuBIeGUQ4WiiFmsDobrHGsvN"
Message-ID: <ae75fd79-1ab1-7353-6e67-b0a10fd70489@erg.abdn.ac.uk>
Date: Sat, 09 Apr 2022 09:00:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
To: "touch@strayalpha.com" <touch@strayalpha.com>, "C. M. Heard" <heard@pobox.com>
Cc: Erik Auerswald <auerswal@unix-ag.uni-kl.de>, TSVWG <tsvwg@ietf.org>
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> <0E681C1B-0CB2-4C66-BBA3-A7BE4B15B65A@strayalpha.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
In-Reply-To: <0E681C1B-0CB2-4C66-BBA3-A7BE4B15B65A@strayalpha.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PrS3S3IMO89BmUZM_nYwZgdGecM>
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: Sat, 09 Apr 2022 08:00:42 -0000

On 09/04/2022 00:42, touch@strayalpha.com wrote:
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://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
>
>
Shouldn't we be refering to RFC 8200 instead, which I think is slightly 
clearer?

Gorry

v2.23.0 | Report a Bug | By Email