Subject: Re: [tsvwg] UDP/IP outer as an IP-shim-IP tunnel and AMT as an example

From: "Holland, Jake" <[email-masked]>
Date: Wed, 2 Aug 2017 19:35:48 +0000

Hi Bob,

Thanks for looking into my AMT question and following up.

A few comments and questions:
1. I agree that your proposed addition covers a gap that was implied but not stated by section 4.3 of RFC 6040.

2. I’m not understanding something: what is it about a protocol that makes it a generic IP-inside-UDP encapsulation that doesn’t need to be explicitly mentioned by the shim-update, vs. encapsulations that do need an explicit update?

Maybe I’m misunderstanding, but an AMT Data packet (https://tools.ietf.org/html/rfc7450#section-5.1.6) on the wire looks like [L2]-IP-UDP-AMT-IP-..., and I think it’s correct that the new ECN requirements in section 4 would apply in a way that I don’t see how it’s different from GRE or Teredo. (Except maybe that it’s unlikely ever to carry TCP in the inner IP; is that the distinguishing factor?)

draft-ietf-tsvwg-rfc6040update-shim-04 proposes to update Teredo and GRE but not AMT, even though it seems from section 5.1 that both GRE and Teredo also have the same kind of “probably existing implementations are already compatible-mode in practice” status under RFC 6040. But I’m not clear on why some of the protocols get an explicit mention and others don’t.

3. Related: What makes it impractical to update all the IP-inside-UDP RFCs?

It seems to me like it would be useful, because whether I’m an implementer or a network operator, if I implement or deploy a protocol such as AMT, today I get no hint from https://tools.ietf.org/html/rfc7450 or from the RFC index that I have any responsibilities regarding ECN.

But if the page for RFC 7450 had the “Updated by” link at the top pointing to the new update-shim document, both these cases seem much more likely to have their ECN behavior considered during a normal round of due diligence.

It also seems justifiable to update all such protocols, because section 4 of draft-ietf-tsvwg-rfc6040update-shim-04 does impose new requirements, even if (as section 4 argues) the requirements are not expected to change any existing implementation’s actual compliance status, since it’s probably already doing compatible-mode.

Is there a good list of existing IP-shim-IP tunnel protocols that the 6040 update-shim document applies to? Is it feasible to include one in this document, whether or not this document will explicitly update them?

Today that project seems to be left as an exercise for the network operator, if RFC8085/BCP145 is the suggested answer.

Kind regards, and thanks again.

Jake

On 7/20/17, 2:26 AM, "Bob Briscoe" <[email-masked]<mailto:[email-masked]>> wrote:

David (as doc shepherd),

In the tsvwg mtg onTue, it was suggested that AMT ought to be included in the list of RFCs that define a new IP-shim-IP tunnelling protocol.

I said that I had actually looked at this and decided not to include it. I now remember why. It was cos AMT is just using UDP-IP encapsulation, not really defining a new encapsulation.

Nonetheless thanks to the guy who came to the mic (sry I can't remember the name - I think from Akamai) for making me revisit this. It identifies a gap: rfc6040update-shim doesn't mention general use of UDP-IP encapsulation. It only mentions the specific case of GUE (generic UDP encapsulation).

The way I propose to handle this is to add a bullet in 5.  IP-in-IP Tunnels with Tightly Coupled Shim Headers<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Drfc6040update-2Dshim-2D04-23section-2D5&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=VM32VUO08UF8Qna2N2K2LeXXaxEJuS5bXaWxlvKSSac&s=DHj4DEzT-tdNKgKJkuD7wryzKTZCEysTcq1XnSUwvGo&e=> for UDP tunnels. Then add the following covering general use of UDP-IP encapsulation, giving AMT as one example of it:

      5.1.x UDP Tunnels

      Section 3.1.11 of the UDP usage guidelines in RFC 8085 already

      explains that a tunnel that encapsulates an IP header within a

      UDP/IP datagram, e.g. Automatic Multicast Tunneling (AMT

      [RFC7450]), needs to follow RFC 6040 when propagating the ECN

      field between inner and outer IP headers.

      The requirements in Section 4 update RFC 6040, so they add

      the important, but previously unstated requirement that, if

      the UDP tunnel egress does not, or might not, support ECN

      propagation, a legacy UDP tunnel ingress has to zero the outer

      ECN field, e.g. by configuration.

Do any RFC's need to be updated? No.
Given the UDP tunnelling section of RFC 8085 (UDP usage guidelines) already refers to RFC 6040, I don't think we need to update every RFC that uses UDP Tunnelling to refer to RFC 6040.

It would be ideal, but perhaps impractical.

Bob

--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/<https://urldefense.proofpoint.com/v2/url?u=http-3A__bobbriscoe.net_&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=VM32VUO08UF8Qna2N2K2LeXXaxEJuS5bXaWxlvKSSac&s=sLmMIa1pa488n_G5PUpLou0aYaFwXxSYz0N9aiSeuw0&e=>