IETF Logo Mail Archive

Re: [IPv6] draft-ietf-6man-hbh-processing

Bob Hinden <bob.hinden@gmail.com> Fri, 28 July 2023 17:09 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 AEB66C14CE27 for <ipv6@ietfa.amsl.com>; Fri, 28 Jul 2023 10:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgYFbrHHc6cu for <ipv6@ietfa.amsl.com>; Fri, 28 Jul 2023 10:09:24 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8E3C14CE54 for <6man@ietf.org>; Fri, 28 Jul 2023 10:09:24 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1b9c368f4b5so22990455ad.0 for <6man@ietf.org>; Fri, 28 Jul 2023 10:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690564164; x=1691168964; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=OFJsBRAc/GazeLA0sKoJW91hsXzV1wdNasrJ2uTA0UU=; b=V8vceJzzL98mY5+Lo5qo6ztdW19JVx8PNeAAY/qKXwu5lKa4OfS5Cc7FMWDzxlnCSD eqvazD3w3drlv/pJRClBgyUZoUH16eIdA14cmavG7CakAZ8DE0H/EjNkNcsxVYs3NwL3 AMRDCqPdoc3z2NBNzOLYd3C5FHqiaPBmrY7ZYiBvX9cb2dlrjwyekFJZM/zZBrC5/gf4 dhETQLsj97Z8w0aswCxMq4Jr8iJM+G1t1BeDEYJWsc8P92+xjhdnKB3STisJRuVSmrQD MNp68u2B+7gg4BpkTQA5MAYWkbYFCPDfVirn4tBW3GVCchwxZ/fNLe6SK1VYpET8RTIT VjKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690564164; x=1691168964; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OFJsBRAc/GazeLA0sKoJW91hsXzV1wdNasrJ2uTA0UU=; b=BlMbzk0x0FP7HgWBcYqstwR1ebGVz68tLyoMa/HhMnJlrsw14hFHQ1iuKSlmtmdThu ofngv1KL8U+8vmY98oNSKtF49XoxXeSB54jKnjInXNb0k9I7Zs1IL7k54Tp+FGi9Az5R 4HG4UTqNomKVVnBNUvlMERXojSYEP5lKB0B5PwG0DHEaLiGpd7OtyWeffrdIi8DcMzWv vkD+pI/LqgDAjKGxiXmz3Y6xE5cfYu1Vx3PCE7Uc1u6Eb56goW1ZK2L97oUh88Rqs26z m1NwsX5vG1t700N6oRdqKK1dugYEmLLvAZhcrkkLJ7+Rf60JoB8cq2hGuu94xTFopUet 47Gg==
X-Gm-Message-State: ABy/qLZ2yJ/zqh3LtZXqFP9Epxzzz0w1lKLLdJJfKfnDqVa79FqyRywc MwKADI4/5rx7bNDN9pFq3Kg84t3GLno=
X-Google-Smtp-Source: APBJJlEt4hy89/N9cJ1+AsJ1LvjdmcJb1RhfvszVRsbpPsAW7kyQtHuLBGOcAj8hns+24x89536nHA==
X-Received: by 2002:a17:902:c94f:b0:1ae:6947:e63b with SMTP id i15-20020a170902c94f00b001ae6947e63bmr2893953pla.16.1690564163609; Fri, 28 Jul 2023 10:09:23 -0700 (PDT)
Received: from smtpclient.apple (dhcp-8b01.meeting.ietf.org. [31.133.139.1]) by smtp.gmail.com with ESMTPSA id jk17-20020a170903331100b001bbce3d4774sm3854300plb.79.2023.07.28.10.09.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2023 10:09:23 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <EBA13102-31B9-455E-B500-143D15A8AC35@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_DB622101-C64F-4169-9DE0-8E2E1A614EA8"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Fri, 28 Jul 2023 10:09:12 -0700
In-Reply-To: <BL0PR05MB531645AB597EC108AC5B2D41AE06A@BL0PR05MB5316.namprd05.prod.outlook.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, "6man@ietf.org" <6man@ietf.org>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
References: <BL0PR05MB531645AB597EC108AC5B2D41AE06A@BL0PR05MB5316.namprd05.prod.outlook.com>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7siCay-KOVIa9vBwfmPfExrDJ4U>
Subject: Re: [IPv6] draft-ietf-6man-hbh-processing
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 28 Jul 2023 17:09:29 -0000

Ron,

> On Jul 28, 2023, at 9:52 AM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> 
> Bob, Gorry,
> 
> Over the past decade, my thinking regarding the HBH Options extension header has evolved and I am wondering whether it makes sense to redefine HBH processing.
> 
> The Internet is a loosely confederated group of “limited domains”. Each limited domain maintains its own forwarding and routing policy. HBH processing, as it is defined in RFC 8200, is OK within a limited domain. It provides yet another tool for deployment of that limited domain’s forwarding and policies.

Seems to me that HBH options usage can be much broader than being limited to ones that are intended to influencing a limited domain’s forwarding and routing policies.   BTW, do you mean influence how a packet containing a HBH option is handled?   I can’t think of any that change a networks forwarding and policies.   Examples?

> 
> Deployment of the HBH across limited domains may not be a very good idea, because it provides a tool for one limited domain to influence the forwarding and routing polices of another. Can you think of a single HBH option for which the above statement is not true? (The question is not rhetorical.)

I am not sure I  follow what you are saying, but not all HBH options are intended to influence the forwarding and routing domain.   A good example of the kind of HBH option we are thinking about is:

RFC 9268 "IPv6 Minimum Path MTU Hop-by-Hop Option”.

HBH options that would be useful across the Internet.

Bob




> 
> I realize that such an HBH option may be defined in the future. But why redefine HBH extension header processing before that option is defined?
> 
> I apologize for raising this issue so late in the game. It took a while for my thinking to evolve.
> 
>                                                                              Ron
> 
> 
> 
> Juniper Business Use Only
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org <mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email