Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
draft-ietf-tsvwg-rfc6040update-shim-02

Document Type Active Internet-Draft (tsvwg WG)
Last updated 2017-06-16
Replaces draft-briscoe-tsvwg-rfc6040bis, draft-briscoe-tsvwg-rfc6040update-shim
Stream IETF
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream WG state WG Document (wg milestone: Sep 2017 - Submit 'Propagating ... )
Document shepherd David Black
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to "David Black" <david.black@dell.com>
Transport Area Working Group                                  B. Briscoe
Internet-Draft                                Simula Research Laboratory
Updates: 6040, 2661, 2784, 3931, 4380                      June 16, 2017
         (if approved)
Intended status: Standards Track
Expires: December 18, 2017

 Propagating Explicit Congestion Notification Across IP Tunnel Headers
                          Separated by a Shim
                 draft-ietf-tsvwg-rfc6040update-shim-02

Abstract

   RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
   rules for propagation of ECN consistent for all forms of IP in IP
   tunnel.  This specification extends the scope of RFC 6040 to include
   tunnels where two IP headers are separated by at least one shim
   header that is not sufficient on its own for packet forwarding.  It
   surveys widely deployed IP tunnelling protocols separated by a shim
   and updates the specifications of those that do not mention ECN
   propagation (L2TPv2, L2TPv3, GRE and Teredo).  The specification also
   updates RFC 6040 with configuration requirements needed to make any
   legacy tunnel ingress safe.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 18, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Briscoe                 Expires December 18, 2017               [Page 1]
Internet-Draft   Propagating ECN between IP-shim-(L2)-IP       June 2017

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IP-in-IP Tunnels with Tightly Coupled Shim Headers  . . . . .   3
     3.1.  Scope of RFC 6040 . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Making a non-ECN Tunnel Ingress Safe by Configuration . .   4
     3.3.  Specific Updates to Protocols under IETF Change Control .   6
       3.3.1.  L2TP (v2 and v3) ECN Extension  . . . . . . . . . . .   8
       3.3.2.  GRE . . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.3.3.  Teredo  . . . . . . . . . . . . . . . . . . . . . . .  11
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Comments Solicited  . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   RFC 6040 on "Tunnelling of Explicit Congestion Notification"
   [RFC6040] made the rules for propagation of Explicit Congestion
   Notification (ECN [RFC3168]) consistent for all forms of IP in IP
   tunnel.

   A common pattern for many tunnelling protocols is to encapsulate an
   inner IP header (v4 or v6) with shim header(s) then an outer IP
   header (v4 or v6).  Some of these shim headers are designed as
   generic encapsulations, so they do not necessarily directly
   encapsulate an inner IP header.  Instead they can encapsulate headers
   such as link-layer (L2) protocols that in turn often encapsulate IP.

   To clear up confusion, this specification clarifies that the scope of
   RFC 6040 includes any IP-in-IP tunnel, including those with shim
   header(s) and other encapsulations between the IP headers.  Where
Show full document text