Re: Inserting Extension Headers or not [was rfc2460bis question ]

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 28 April 2016 03:26 UTC

Return-Path: <brian.e.carpenter@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 BF96812D562 for <ipv6@ietfa.amsl.com>; Wed, 27 Apr 2016 20:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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] autolearn=ham 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 jZd8XxOp5eDD for <ipv6@ietfa.amsl.com>; Wed, 27 Apr 2016 20:26:33 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 0F8BA12D524 for <ipv6@ietf.org>; Wed, 27 Apr 2016 20:26:33 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id n1so31437822pfn.2 for <ipv6@ietf.org>; Wed, 27 Apr 2016 20:26:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dOJR1hslRevStF8dbR7nmquo4A1IrnnWSz2Nk9mkFMs=; b=Tl5E3gJ2PUUJ3z1pzU9J1Ep9n2fQ6R9sz/th0MXJ1ILDI7CNWbERn+QEzPQ/6S5abc psW5AC7Hso7Is1Ucwhx3xFyGxobCy6lRW7tM4gHvgBI/r77ABFwi7oFXmaG5NnVi+f90 GyMM0D5l96bXRCz5QjvO9HkvYaBRaO3xWmwUYYMkfU5h4vVNEh2J/7gCCCpnW92FGEgI pPqrp2R+dEiNFK2NkrFs+DHIrQ4mAEurGLtgF9fyo9qrE+leQXZ5UFZ/IkmLBF0D+f2d BPVkgSunAz7A8MnphzmkdwrmERJGI0pT3PM0dxnkcHT3J5FRL7ahfVCx6JKtPaTIQQ5Q eMpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=dOJR1hslRevStF8dbR7nmquo4A1IrnnWSz2Nk9mkFMs=; b=QCn9gDIPMrIKL4B47PL7oBsQNQ24gRdz5ZRHwqlw0umkEU7cmUjY+Wd+n+R6XMnBCt oP2oPvStdPvU4Qe+SI4zuY/KefS6+FKNaUX5ZBBQKS7JWgjbNnJIMyuuiwAoHqjC7HtB vekRp2YgkNjX25pnKEiNZ7dofpT63Ya0afeXaOAU7Pk6xImmTxFkWykS8gNJZaRdjcdJ OW0G/FD0mH8ozbROmMnZ2RQH0+/5DAFaSuxnU9Wc2+GkSXD3PQTs2jVCTyhgcuPObIul jw9KGirlvQsFsQTefYvEidGglppQeCEEnvzMo+8cYzpebJ1vH4/49jTKzpo9f1JV2EHH EL2w==
X-Gm-Message-State: AOPr4FXEl/ezOhboW4WF1D2WBTgbYy9txBgriFnz4rj3l+D4kkEbIUIB18aXmWx1O/oIeQ==
X-Received: by 10.98.23.211 with SMTP id 202mr17110970pfx.122.1461813992592; Wed, 27 Apr 2016 20:26:32 -0700 (PDT)
Received: from ?IPv6:2406:e007:6337:1:28cc:dc4c:9703:6781? ([2406:e007:6337:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x89sm10188689pfa.87.2016.04.27.20.26.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 20:26:31 -0700 (PDT)
Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ]
To: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
References: <E330D833-9CE9-4CEB-9989-26B6E69AA362@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <988dcc9d-102e-735c-68a8-3aaa46059786@gmail.com>
Date: Thu, 28 Apr 2016 15:26:35 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <E330D833-9CE9-4CEB-9989-26B6E69AA362@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/poEU0yz7m2qpx3EACsszktrOlpk>
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, 28 Apr 2016 03:26:36 -0000

On 28/04/2016 13:18, Bob Hinden wrote:
> Hi,
> 
> I would like to get closure on the question if inserting IPv6 extension headers is allowed or not, and should this be a clarification in rfc2460bis.  This topic was discussed in Buenos Aires and on the mailing list.
> 
> The relevant text from Section 4 "IPv6 Extension Headers" in <draft-ietf-6man-rfc2460bis-04.txt>
> 
>    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].
> 
> This text was added to the draft in version —01 published on 2 November 2015.
> 
> The question is if this text was the original intent of rfc2460.  That would allow it to be part of rfc2460bis going to Internet Standard.  If it is a change, then it should not be included.
> 
> In my personal view (as one of the authors of rfc2460), I think it was the original intent to not allow extension headers to be inserted.  My thinking is that not allowing extension headers to be inserted is related the design of IPv6 that includes only supporting fragmentation at the source.  IPv4 allows the addition of options resulting in changing the header length, but it includes per-hop fragmentation so any resulting MTU issues can be dealt with.  Even IPv4 fragments can be fragmented.  I think it is a consequence of IPv6 not allow per-hop fragmentation, that extension headers were not intended to be inserted along the path to the destination.

I think this exactly correct. I did a bit of archaeology and found the message
where Steve Deering summarised the issues resolved before RFC 1883 (the predecessor
of RFC 2460) was published in 1995. I've attached it below - look just after
"rejected at the Stockholm meeting" i.e. IETF 33. The comment that triggered
it was in message (IPng 346) from Charlie Lynn sent 30 June 1995.

[I knew my mail archives would be useful one day.]

    Brian

> Note, I think it would be fine for someone to document how to do extension header insertion, as long as they describe how it works, and how to deal issues like MTU problems.  This can be be an update to rfc2460bis (after it is published).
> 
> However, I do not think leaving the rfc2460bis text in an ambiguous state on this topic is a good idea.
> 
> Comments?
> 
> Thanks,
> Bob

-------- Forwarded Message --------
Subject: (IPng 609) changes to Last Call'ed specs
Date: Sun, 27 Aug 1995 20:59:26 PDT
From: Steve Deering <deering@parc.xerox.com>
To: ipng@sunroof.eng.sun.com
CC: deering@parc.xerox.com

At the request of our ADs, I prepared the following list of agreed-upon
changes and outstanding issues with the set of specs that underwent
IETF-wide Last Call in June and July.  Please let me know of any errors
or omissions.

Steve

===================================

IPv6 Specification
------------------

The following changes were posted to the IETF list immediately following
the Last Call, so I think we can consider them to also have been Last Called:

  - In the examples of how to lay out options, on page 29, two places
    where it says "Hdr Ext Len=1" should be "Hdr Ext Len=3"
    (reported by Hamid Asayesh).

  - In section 6, Flow Labels, I forgot to include the Priority field
    in the list of fields that must have the same value for all
    packets in the same flow (reported by Markus Jork).

  - The description of what the Jumbo Payload Length field covers
    should be made clearer (reported by Christian Huitema).

The following changes were proposed by Charlie Lynn in the only "formal"
response to the Last Call, and accepted at the first ipngwg meeting in
Stockholm:

  - For options containing data that can change en-route (and which therefore
    have the third-highest-order bit of their Option Type set to 1), make it
    clear that *all* bytes of the Option Data field are to be excluded from
    the Authentication function, and explain that "excluded" means "treated
    as if they were all zero-valued bytes".

  - Change the Routing Header to enable it to be ignored by final destinations
    that do not understand the Routing Type.  In Stockholm, Deering proposed,
    and the attendees agreed with, the following revised format for the
    first 32 bits of the Routing Header, for all Routing Types:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |

    where

	Hdr Ext Len   is the length of the header in 8-octet units, not
	              including the first 8 octets

	Segments Left is the number of "legs" left to traverse in the
                      route; if this value is zero, the receiver may
	              ignore this header (i.e., it indicates that the
	              route has been completed), whether or not the
	              receiver understands the Routing Type

The following additional changes were agreed to either on the mailing list
or in the Stockholm meetings:

  - "Improve" the host/router terminology.  What I propose to do is add a
    footnote to the terminology section saying something like this:

	* it is possible, though unusual, to have a device with multiple
          interfaces configured to forward non-self-destined packets
          arriving from some set (fewer than all) of its interfaces, and
	  to discard non-self-destined packets arriving from its other
	  interfaces.  Such a device must obey the protocol requirements
	  for routers when receiving packets from, and interacting with
	  neighbors over, the former (forwarding) interfaces.  It must
	  obey the protocol requirements for hosts when receiving packets
	  from, and interacting with neighbors over, the latter (non-
	  forwarding) interfaces.

    Comments?

  - Clarify the operation of Type 0 Routing Header by giving an example,
    showing the values of the header fields on each segment of the route.

  - Clarify the handling of options, extension headers, Next Header fields,
    etc. for fragmented packets by giving a few examples of packets before
    and after fragmentation (suggested by Dimitry Haskins and others).

  - Specify that fragments cannot reassemble to form a jumbogram (suggested
    by Craig Metz).


ICMPv6 Specification
--------------------

  - Add note warning about the possibility of upper-layer header being
    truncated from the returned packet in an error message, due to large
    number of extension header bytes, which can defeat delivery of the
    error message to the guilty upper-layer protocol instance.

  - Delete description of pseudo-header, replacing it with a reference to
    the description in the IPv6 spec (suggested by Alistair Bell and
    Marc Hasson).

  - Correct example of usage of the pointer in the Parameter Problem
    message on page 15, by changing "48" to "40" (reported by Dimitry
    Haskins and Francis Dupont).

  - Note that there is another exception to the "no ICMP error messages
    in response to multicasts" rule, which is "unrecognized option"
    Parameter Problem messages in response to options with high-order
    bits "10..." (reported by Dimity Haskins).

Address Architecture Document
-----------------------------

  - Add definition of "link-local address" to the terminology section
    (suggested by Jim Bound).

  - Specify that "::" is a legal text representation of the Unspecified
    (all-zeros) Address (suggested by Francis Dupont).

===================================

The following suggestions in Charlie Lynn's formal response to the Last Call
were rejected at the Stockholm meeting:

  - Add a bit to the Routing Header indicating whether or not it was
    inserted into the packet en-route, i.e., by a node other than the
    packet's originator.

      reasons for rejection: insertion of extension headers en-route breaks
      PMTU-discovery and can result in ICMP error messages being sent to
      non-guilty parties.  The desired effect can be achieved, and those
      problems avoided, by using en-route encapsulation (with optional
      Routing Header) rather than header insertion.

  - Change ICMP error messages to contain explicit fields identifying the
    upper-layer protocol to which the error message should be delivered.

      reasons for rejection: considered unnecessary complexity to handle the
      rare case of truncation of transport header from the returned packet
      because of too many extension header octets.  Such error messages are
      still usable for problem diagnosis other than in the upper-layer
      itself, e.g., if logged at IPv6 layer or observed in a packet trace.
      Will add warning to the ICMPv6 spec about consequences of long
      extension header on ICMP error message dispatching.

  - Change Security Considerations section of ICMPv6 spec to specify when
    and how to include an Authentication Header in ICMP error messages.

      reasons for rejection: group consensus that this belongs in aa
      IPsec spec instead.

===================================

The following issues and suggestions have been discussed on the mailing list
since the base specs went to Last Call, but no group consensus on these issues
has been reached yet:

  - Fragmentation issues:
	- change the minimum reassembly buffer size to a number larger
	  than 576?
	- specify that sources of fragmented packets must use the minimal
	  number of fragments required to fit in the perceived PMTU?
	- specify that all fragments with the M bit set must be no less
	  than 7 octets shorter than the perceived PMTU?
	- specify that all fragments with the M bit set must be no shorter
	  than 576 octets?
	- ignore fragments that partially overlap other fragments of the
	  same packet, or discard any packet that arrives as partially
	  overlapping fragments?

  - Routing Header issues:
	- add a "Total Length" field to the fragment header, carrying the
	  length of the original, unfragmented packet?
	- forbid forwarding of packets with Routing Headers by hosts?
	  (if not, make it clearer that hosts are expected to forward
	  packets with Routing Headers, if they are intermediate targets
	  of such packets.)
	- specify the reversing rules for packets that are responses to
	  packets that carry a Routing Header?
	- forbid or discourage reversal of an unauthenticated Routing Header?
	- forbid or discourage acceptance of a packet with an unauthenticated
	  Routing Header?

  - Allow the transport-layer checksum to be omitted when the Authentication
    header (or the ESP header?) is being used?

  - Add a Congestion Indication bit to the base IPv6 header?

  - Add MUST/SHOULD/MAY conformance requirements for all IPv6 fields and
    functions?

  - Build a single Terminology document, to be shared (either by reference
    or inclusion) in all IPv6-related specs?

  - Allow the use of zero in the UDP Length field to indicate that the UDP
    length should be derived from the Jumbogram Option?

Note: the above list does not include issues concerning those specs that
have not yet been subjected to WG or IETF Last Call, e.g., the Neighbor
Discovery spec.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com