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

[Erik Auerswald <[e-mail]>]

Hi,

On 09.04.22 01:42, [e-mail] wrote:
>> On Apr 8, 2022, at 4:16 PM, C. M. Heard <[e-mail]> 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...

I concur that the text in RFC 4380 section 5.2.3 seems to be
a bit unclear.  I do not think it is wrong.

A possible interpretation could be that RFC 2460 (back then)
specified IPv6 and thus how to determine the length of the
encapsulated IPv6 packet.

This length needs to fit into the available space in the
encapsulating UDP datagram, possibly after subtracting the
space used by Teredo's Origin Indication and/or Authentication
encapsulations.

Since Teredo is explicitly an IPv6 over IPv4 tunneling
mechanism using IPv4+UDP for NAT Traversal, as opposed to a
generic UDP based tunneling mechanism, it seems likely that
an implementer would be able to come to this conclusion from
the existing description.

Thus I do not think that this warrants an errata report
against RFC 4380.

Best regards,
Erik