Eric Rescorla's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT)
Eric Rescorla <ekr@rtfm.com> Fri, 21 April 2017 22:39 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7065129407; Fri, 21 Apr 2017 15:39:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan <otroan@employees.org>, 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org
Subject: Eric Rescorla's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149281434180.25836.10818713217769164593.idtracker@ietfa.amsl.com>
Date: Fri, 21 Apr 2017 15:39:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/oq6tbl5q9huH96VMIVQl9w5zPCk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 21 Apr 2017 22:39:02 -0000
Eric Rescorla has entered the following ballot position for draft-ietf-6man-rfc2460bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I get that this document is from a period before the style became as uniformly to upper-casify RFC2119 keywords, but but it seems like it might be a good idea to do that here. It's a little hard to determine what is normative here, but S 4. says A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Fragment Destination Options Routing Authentication Encapsulating Security Payload Given that 6434-bis seems to have backed away from IPsec, this document needs to as well. S 4.4. Assuming I am reading this document correctly (and I've never implemented v6 so I could be crazy), in order to implement the routing header you need to decrement Segments Left, but the document does not seem to say that. S 4.5. As I read this document the order of headers is only strongly recommended, but the rules about fragmentation seem to absolutely require a specific order: The Per-Fragment Headers consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. Is there a reason why the rules are not MUST? S 4.5. The following conditions are not expected to occur, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. If fragments follow different paths (not crazy) then the hop limit will be different, right? So perhaps "not expected" is a bit strong. S 8.4. Response packets that carry Routing headers that were derived by reversing the Routing header of the received packet IF AND ONLY IF the integrity and authenticity of the Source Address and Routing header from the received packet have been verified by the responder. It's not clear to me how this works. If, as I suggest above, the routing header gets changed in transit, how do you measure the integrity and authenticity? Even if that is not the case, and you use something like IPsec to provide integrity, why do you trust whatever claims the sender makes about routing.
- Eric Rescorla's No Objection on draft-ietf-6man-r… Eric Rescorla