[IPv6]Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)
Jim Guichard via Datatracker <noreply@ietf.org> Wed, 29 May 2024 21:55 UTC
Return-Path: <noreply@ietf.org>
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 78F48C169410; Wed, 29 May 2024 14:55:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Jim Guichard via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171701972848.56003.16015982163088058594@ietfa.amsl.com>
Date: Wed, 29 May 2024 14:55:28 -0700
Message-ID-Hash: KNUKK7KCXK74VA46XSQSBW2KGYW7U6ZE
X-Message-ID-Hash: KNUKK7KCXK74VA46XSQSBW2KGYW7U6ZE
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-6man-comp-rtg-hdr@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, bob.hinden@gmail.com
X-Mailman-Version: 3.3.9rc4
Reply-To: Jim Guichard <james.n.guichard@futurewei.com>
Subject: [IPv6]Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/o0p8W9Vtv5C29yWLvR-pLYneuY8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>
Jim Guichard has entered the following ballot position for draft-ietf-6man-comp-rtg-hdr-08: Discuss 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to DISCUSS Section 7 of the document as I have a few concerns and question whether the section is even necessary. The relevant text from this section is as follows: When a packet containing the CRH header leaves its source, it does not include its final destination address. The final destination address is not added to the packet until the final CRH SID is resolved. Jim> This first paragraph just seems to document what routing headers do - the IPv6 destination address of the packet is not the final destination as carried in the last entry in the routing header. Okay, got that but then the text jumps to talk about address transparency but this concept is nothing new in the presence of routing headers. While destination address transparency enhances privacy, it prevents intermediate nodes from verifying transport layer checksums. Jim> Now the text introduces the notion that address transparency somehow enhances privacy - how and why is that relevant? I think you are trying to highlight that because addresses that are not the ultimate destination are carried in the IPv6 destination address, and the routing header may have one or more other addresses (these being the 'transparent' ones), then an intermediate node might have trouble verifying transport layer checksums. If so, why not just say if you use CRH then intermediate nodes may not be able to calculate transport layer checksums unless they are CRH aware? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few additional comments (I have included line numbers from idnits for the latest version): 18 This document describes an experiment in which two new IPv6 Routing 19 headers are implemented and deployed. Collectively, they are called 20 the Compact Routing Headers (CRH). Individually, they are called 21 CRH-16 and CRH-32. Jim> This first paragraph seems to overlap with the second paragraph with its discussion of implementation and deployment. Perhaps reword it as follows as the second paragraph is clear enough as to the purpose of the experiment. This document describes an experiment in which two new IPv6 Routing headers are defined; Collectively called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32. 89 1. Introduction 91 IPv6 [RFC8200] source nodes use Routing headers to specify the path 92 that a packet takes to its destination. The IETF has defined several 93 Routing header types [IANA-RH]. This document defines two new Jim> [IANA-RH] defines ‘Routing Types’ not ‘Routing header types’. It would be more precise to just say ‘Routing Types’. 107 * Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely 108 reliable, many IPv6 hosts refrain from sending packets larger than 109 the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are 110 small, the overhead imposed by large Routing Headers is excessive. Jim> The above text is making a statement that may or may not be true dependent upon who one talks to ;-) I would suggest to say, ‘large Routing Headers may be excessive’. 207 The topological function specifies how the processing node forwards 208 the packet to the interface identified by the IPv6 address. The 209 following are examples: Jim> Is this an exhaustive list? If not, please specify that. 232 The above-mentoned mechanisms are not defined here and are beyond the Jim> s/above-mentoned/above-mentioned 250 * If L is greater than Hdr Ext Len, discard the packet and send an 251 ICMPv6 Parameter Problem, Code 0, message to the Source Address, 252 pointing to the Segments Left field. Jim> Why would the ICMPv6 message point to the Segments Left field? Shouldn’t it point to the Hdr Ext Len field? 332 8. Applications And SIDs Jim> s/Applications And SIDs/Applications and SIDs
- [IPv6]Jim Guichard's Discuss on draft-ietf-6man-c… Jim Guichard via Datatracker
- [IPv6]Re: Jim Guichard's Discuss on draft-ietf-6m… Ron Bonica
- [IPv6]Re: Jim Guichard's Discuss on draft-ietf-6m… James Guichard
- [IPv6]Re: Jim Guichard's Discuss on draft-ietf-6m… James Guichard