Next steps on Extension Header Insertion

Bob Hinden <bob.hinden@gmail.com> Thu, 27 October 2016 19:03 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65721129699 for <ipv6@ietfa.amsl.com>; Thu, 27 Oct 2016 12:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level:
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_GREY=0.424] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsS9o_xIOidy for <ipv6@ietfa.amsl.com>; Thu, 27 Oct 2016 12:03:23 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB0B1296CE for <ipv6@ietf.org>; Thu, 27 Oct 2016 12:02:34 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id p22so40349370ywe.0 for <ipv6@ietf.org>; Thu, 27 Oct 2016 12:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=zDo9pvPQZC5tSmGDdtOlxvTM3H5/vz6aPDF+60shvBU=; b=P4BM3h2E533KybK3ZFgBmcdJzaeVPKovKoDhCr0rrLUfgkUW9UTErOEa157+Wv5FSR sEe31sM7apDM3TznFaCEnvVcvA7ZlKA4Vy6XGd6coD0IhxhJRY1pGYENjKTd8KuUaxfU 5XpJMs0qhlJ7o+AI0BiIDBJ4pQJ7plNO07fRSJNTuJKGjj/5ocDNPFujFiMvTRQ3W+Oy wAl8kf9D/xpRyc54mZKiOv1r6scaRlmtyDFEe3iFRiTMFa5TO4aBe8A4ydv4J3by6kzn a5G62Aevn83OZcKLOkfHK7P79LG0GAbtiuvmyoCQ+JmYuALZp9uXptL4vPo4NEO6Mdyd PgdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=zDo9pvPQZC5tSmGDdtOlxvTM3H5/vz6aPDF+60shvBU=; b=IJ0aYqyjP/X42dVUS7NKava8o3XgcSfHSfNCB5e9wlUc9QqKnf17wyX5QvKmQ6sHjy p/vDaztRi0jZ2gRSZu0MFOnr34+qJE4S44rXsYpMvJzrv76Jq7NFO128iTvgtYftSDPq D+zt5XH2iviaSHxTdkTXCTQWhmV13Na1hqS5r5t2KK8spNHYC5ta8NJJmncM13tRNBNi 0oSgUOG6XDp1vkJvnRSQ/hXLFh/RCCH1uMSw2cykymeny88hLYOMqD9cRkMePWZ9gksm DJD9QPDojbEfq2zqTUuWK53aNGsFHcPW7uivPquu4wtBKyXvfhuOemMvINS78+SnyBYU PZ7g==
X-Gm-Message-State: ABUngvfRuouZlMKXfwM8gFgaqpy9eXzjSPvP2y8pmAzkUqBuwKU2YodUGgHjH0YFR7furQ==
X-Received: by 10.107.20.85 with SMTP id 82mr8286344iou.187.1477594954050; Thu, 27 Oct 2016 12:02:34 -0700 (PDT)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id b6sm3416846iob.4.2016.10.27.12.02.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Oct 2016 12:02:33 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_EAFDD73B-8CE4-4A9B-8546-D7409C31A35B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Subject: Next steps on Extension Header Insertion
Date: Thu, 27 Oct 2016 12:02:32 -0700
Message-Id: <B291E9E6-A803-423F-BFA5-87A74DCFB784@gmail.com>
To: IPv6 List <ipv6@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/AtY92TpJ3vvmiidzcPkJdXKZQIA>
Cc: Bob Hinden <bob.hinden@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Oct 2016 19:03:24 -0000

Hello,

The chairs believe the bis drafts for moving the IPv6 to Internet Standard are close to being done with one exception, text in rfc2460bis on Extension Header Insertion.  This topic has been discussed extensively on the list and in working group sessions.  Prior to declaring a consensus and advancing the documents to the IESG we would like some feedback from the working group.

The current text regarding header insertion in draft-ietf-6man-rfc2460bis-07.txt (and has been there since the -05) is:

  The insertion of Extension Headers by any node other than the source
  of the packet breaks PMTU-discovery and can result in ICMP error
  messages being sent to the source of the packet that did not insert
  the header.

  The current approach to allowing a header to be inserted is to
  encapsulate the packet using another IPv6 header and including the
  additional extension header after the first IPv6 header, for example,
  as defined in [RFC2473].

Based on recent face to face and mailing list discussions, we think the text could be improved as follows:

  The insertion of Extension Headers by any node other than the source
  of the packet causes serious problems.  Two examples include breaking
  the integrity checks provided by the Authentication Header Integrity
  [RFC4302], and breaking Path MTU Discovery and can
  result in ICMP error messages being sent to the source of the packet
  that did not insert the header.

  One approach to avoid these problems is to encapsulate the packet
  using another IPv6 header and including the additional extension header
  after the first IPv6 header, for example, as defined in [RFC2473]

The change in the first paragraph is more accurate as it notes there is more than one problem.  The change in the second paragraph makes it clear that encapsulation isn’t necessarily the only approach.

Our current take after reviewing the discussion in Berlin and on the mailing list we think there is consensus on the first paragraph as it accurately describes the issue with header insertion.  There is a much rougher consensus on the second paragraph, but don’t see it as the real issue which is the first paragraph.

While we both think that the intent of IPv6 was not to support header insertion we don’t see there being a consensus in the working group ban it outright as was proposed in the -01 draft:

  Extension headers must never be inserted by any node other than the
  source of the packet.  IP Encapsulation must be used to meet any
  requirement for inserting headers, for example, as defined in
  [RFC2473].

We think the choice before the working group at this point is to either do something like the proposed text, or to not say anything at all about this topic.  This would be no change from RFC2460.   We would like your feedback on these choices between now and 13 October.  We have created a survey so we can better gauge where the working group is.  We are hoping that by using the survey, we will get more responses then by email alone.

To summarize, we think there are three choices.

(A) Banning header insertion outright:

  Extension headers must never be inserted by any node other than the
  source of the packet.  IP Encapsulation must be used to meet any
  requirement for inserting headers, for example, as defined in
  [RFC2473].

(B) Describe the problems caused by header insertion:

  The insertion of Extension Headers by any node other than the source
  of the packet causes serious problems.  Two examples include breaking
  the integrity checks provided by the Authentication Header Integrity
  [RFC4302], and breaking Path MTU Discovery and can
  result in ICMP error messages being sent to the source of the packet
  that did not insert the header.

  One approach to avoid these problems is to encapsulate the packet
  using another IPv6 header and including the additional extension header
  after the first IPv6 header, for example, as defined in [RFC2473]

(C) Not say anything at all about header insertion in rfc2460bis

  [No text in rfc2460bis about header insertion]

Note: If in case (B) or (C), it might be good to write a new draft that describes the issue in depth and makes recommendations.  We could then see if we can build a consensus around a draft like that, but it would be separate from the effort to move the IPv6 specifications to Internet Standard.

Please fill in the poll at

    https://www.surveymonkey.com/r/QG5QPVR

before November 4, 2016.  The poll allows you to express you preference for each choice, with 1 being the highest preference, and 3 being the lowest.  We will publish the results after the poll closes.

Thanks,
Bob & Ole