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

["[e-mail]" <[e-mail]>]

Hi, all,

> On Apr 8, 2022, at 12:11 PM, C. M. Heard <[e-mail]> wrote:
> 
> On Fri, Apr 8, 2022 at 7:13 AM Erik Auerswald wrote:
> >
> > 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.
> 
> 
> 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.

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

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

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

Joe