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

From: Erik Auerswald <[email-masked]>
Date: Fri, 8 Apr 2022 16:13:18 +0200

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

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 8 Apr 2022 12:11:28 -0700

> RFC 6081 from draft-ietf-tsvwg-udp-options.

Greetings Erik,

After reading your rationale and having a look at the RFCs, I agree
with the above suggestion. Fundamentally, the issue is that this
sentence

   IPv6 Teredo [RFC6081] uses values of the UDP Length that are larger
   than the IP payload as an additional type of signal, as noted in
   Section 20.

results from a misunderstanding of the following text from

   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.

   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.

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 8 Apr 2022 15:42:21 -0700

Hi, all,

> On Apr 8, 2022, at 12:11 PM, C. M. Heard <[email-masked]> wrote:
> 

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 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. 

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

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 8 Apr 2022 16:16:27 -0700

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

> 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.
>

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

> 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

+1

Mike

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 8 Apr 2022 16:42:27 -0700

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

> On Apr 8, 2022, at 4:16 PM, C. M. Heard <[email-masked]> wrote:
> 
> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 9 Apr 2022 09:00:21 +0100

On 09/04/2022 00:42, [email-masked] wrote:
> www.strayalpha.com <http://www.strayalpha.com>
>
>>     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.
>>
> 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.
>
Shouldn't we be refering to RFC 8200 instead, which I think is slightly 
clearer?

Gorry

---

From: Erik Auerswald <[email-masked]>
Date: Sat, 9 Apr 2022 12:40:20 +0200

Hi,

> 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

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 9 Apr 2022 08:57:47 -0700

On Sat, Apr 9, 2022 at 3:40 AM Erik Auerswald wrote:
> [ ... ] I do not think that this warrants an errata report
> against RFC 4380.

+1

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 9 Apr 2022 09:23:59 -0700

> On Apr 9, 2022, at 3:40 AM, Erik Auerswald <[email-masked]> wrote:
> 
> Hi,
> 

“Conforms to 2460” is explained with the text after the colon.

The only part of that text that defines conformance is the protocol ID.

Nothing in 2460 asserts anything about the IPv6 length being consistent with the length of the protocol in which that IPv6 is placed as payload. 8200 says nothing about this either.

Either way, the authors of those docs and their ADs can decide what to do with the errata.

Joe