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
- Inserting Extension Headers or not [was rfc2460bi… Bob Hinden
- Re: Inserting Extension Headers or not [was rfc24… Fernando Gont
- Re: Inserting Extension Headers or not [was rfc24… Mark Smith
- Re: Inserting Extension Headers or not [was rfc24… Brian E Carpenter
- Re: Inserting Extension Headers or not [was rfc24… Tim Chown
- Re: Inserting Extension Headers or not [was rfc24… Stefano Previdi (sprevidi)
- Re: Inserting Extension Headers or not [was rfc24… Tom Herbert
- Re: Inserting Extension Headers or not [was rfc24… Tim Chown
- Re: Inserting Extension Headers or not [was rfc24… Stefano Previdi (sprevidi)
- RE: Inserting Extension Headers or not [was rfc24… Ronald Bonica
- Re: Inserting Extension Headers or not [was rfc24… Ralph Droms
- Re: Inserting Extension Headers or not [was rfc24… Fernando Gont
- Re: Inserting Extension Headers or not [was rfc24… 神明達哉
- Re: Inserting Extension Headers or not [was rfc24… Michael Richardson
- Re: Inserting Extension Headers or not [was rfc24… Mark Smith
- Re: Inserting Extension Headers or not [was rfc24… Bob Hinden
- Re: Inserting Extension Headers or not [was rfc24… Bob Hinden
- Re: Inserting Extension Headers or not [was rfc24… Mark Smith
- Re: Inserting Extension Headers or not [was rfc24… Brian E Carpenter
- Re: Inserting Extension Headers or not [was rfc24… Tom Herbert
- RE: Inserting Extension Headers or not [was rfc24… Pascal Thubert (pthubert)
- Re: Inserting Extension Headers or not [was rfc24… Michael Richardson
- when Inserting Extension Headers Michael Richardson
- RE: Inserting Extension Headers or not [was rfc24… Pascal Thubert (pthubert)
- Re: Inserting Extension Headers or not [was rfc24… Fernando Gont
- Re: Inserting Extension Headers or not [was rfc24… Bob Hinden
- Re: Inserting Extension Headers or not [was rfc24… Mark Smith
- Re: Inserting Extension Headers or not [was rfc24… Brian E Carpenter
- Re: when Inserting Extension Headers Fernando Gont
- Re: Inserting Extension Headers or not [was rfc24… Fernando Gont
- Re: Inserting Extension Headers or not [was rfc24… Fernando Gont
- Re: Inserting Extension Headers or not [was rfc24… Bob Hinden
- Re: Inserting Extension Headers or not [was rfc24… Brian E Carpenter
- Re: Inserting Extension Headers or not [was rfc24… otroan
- Re: Inserting Extension Headers or not [was rfc24… Brian E Carpenter
- Re: Inserting Extension Headers or not [was rfc24… Tom Herbert
- Re: Inserting Extension Headers or not [was rfc24… Mark Smith
- Re: Inserting Extension Headers or not [was rfc24… otroan
- Re: Inserting Extension Headers or not [was rfc24… Brian E Carpenter
- Re: Inserting Extension Headers or not [was rfc24… Michael Richardson
- Re: Inserting Extension Headers or not [was rfc24… otroan
- Re: Inserting Extension Headers or not [was rfc24… Bob Hinden
- Re: Inserting Extension Headers or not [was rfc24… joel jaeggli
- Re: Inserting Extension Headers or not [was rfc24… Brian E Carpenter