[IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert
Mark Smith <markzzzsmith@gmail.com> Tue, 18 June 2024 04:25 UTC
Return-Path: <markzzzsmith@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 1CC89C19330B; Mon, 17 Jun 2024 21:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.304
X-Spam-Level:
X-Spam-Status: No, score=-6.304 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.3, RCVD_IN_DNSWL_HI=-5, 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 8cpJglCa6RJv; Mon, 17 Jun 2024 21:25:31 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 E9F2DC1930B6; Mon, 17 Jun 2024 21:25:25 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2eaa89464a3so56962651fa.3; Mon, 17 Jun 2024 21:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718684723; x=1719289523; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5j0V72hbdkTq/yao1Theyb3slzUOOCKNVsSyOrXUPvM=; b=Kc/zkivZXrPChYCDDEkmeKbSZ4h93Yj11fSmhmBVt4viiAgUwPTPiyKyR4NIuRWgi0 +ZjvPHJHOxbrDcjCfvQHvUx07Uglfr7/syX/3E+1weQ1p82RFogEUSvDTfEguhxGETiD PrIURY+edersZayASTwR74bZmBcOIpCd4nkpUDtsZEgOpMdENtFHPvnTrmc6rG43JSrD kZeIiLCSfTKYO3/dkJ1TTvjFOUgz1oVer8FunEZJaTSExoDepXoCujhIlaUs1NghSbRu JdRBUj0z9sMB7ke7dd0LZjzYtGVbUGkZ2dy1p70adI/AczGW/uZjwGIPZglAMYPC3pAk tuOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718684723; x=1719289523; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5j0V72hbdkTq/yao1Theyb3slzUOOCKNVsSyOrXUPvM=; b=oHfW5zH+0GqekvJcYYhZq5GDhMsAoR2KaVyC3gN7MzuPK2FsfUjZt0P2SZBmUm1Zwc T1Uz0IfrOc14fagQAVI3BhBUWU+Yp5oT4vlCl80nsR1jw+rPLNv/FTC8gB4OYP+gCuhX IrQKgl9Hwi+j/ulED/+UAK2lWbP2Oe7Yag7iRLbL+KFdVe7ov/pOWUr+9QGJIBJzJ4TZ XvdoE719mN343tgOXXYBUJJZ38ajPo0tvFS7w+DnXKcfqSDWGdsxREcK4cmmgd+MmFcz qtb1iUlKJLFfPt2jso1MvvKFErfjaRTGOXXvDloop42pvFATyJO7jtGqx0D3Mv1QhW3v Ctgg==
X-Forwarded-Encrypted: i=1; AJvYcCWzXmJJJsSHG6RNHGl3WfCyFKTGGIL6y9ERBfdyGqhhcHMvtJNs6zo2RBgiQYFvB6zJ33Z7A07tqDUthxmUYG4+cxA9e1WViOqOM5N45BukoMwE7fPG0b/QWhHo0ydpxxZphMCsTerQCI+g/sTHoUuy4szbZBA7MmP0dvJFUyxJ4WRMiGFfnw==
X-Gm-Message-State: AOJu0YwH60sSxspk23MYKn+c1oMIzq4+ojRgKejpfp445M83ZHmSry+K YRTokkSPciGd4bYZ/uHCLjbGdHptOs4TKHYF7yhrBncDqMT9d0CkqAd11N+/edrM+bNQQ8154st VVEl1C/bPNh4AMOmoyZL1njlpRjs=
X-Google-Smtp-Source: AGHT+IEdHHAcxEtL/ifunKMraprPGnE05GDGAMWz63rdQJmxlc8a3zzJPMHQtnScKS+RAp7PP6Mw8e2s+PU5EC36X7Y=
X-Received: by 2002:a2e:b052:0:b0:2ec:174b:75c1 with SMTP id 38308e7fff4ca-2ec174b77e7mr64137271fa.38.1718684723230; Mon, 17 Jun 2024 21:25:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BAQDP-+bOZOphnxwJopikYxoW=Bvo_1S7czfXmq=2UT2zg@mail.gmail.com> <1C4203A2-9298-414F-A0A2-00BB87A7A2EA@gmail.com> <BL0PR05MB531671B165FE15E2CB5387E0AEC02@BL0PR05MB5316.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB531671B165FE15E2CB5387E0AEC02@BL0PR05MB5316.namprd05.prod.outlook.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 18 Jun 2024 14:24:56 +1000
Message-ID: <CAO42Z2xbhm28wiJe4tG9fF4b4mAkWp+NCRi-DvXSFjgxdGcRYQ@mail.gmail.com>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: HLTZ4MNAH4UKNZUFGBOHX5ZLUP7TAYO4
X-Message-ID-Hash: HLTZ4MNAH4UKNZUFGBOHX5ZLUP7TAYO4
X-MailFrom: markzzzsmith@gmail.com
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: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, "draft-bonica-6man-deprecate-router-alert@ietf.org" <draft-bonica-6man-deprecate-router-alert@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Mdl9wIVN2S1YOePNHRMn1107a3c>
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>
Hi, On Thu, 13 Jun 2024 at 01:11, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote: > > Bob, > > Thanks for posing the most interesting architectural question! > > The HBH Processing draft positions the HBH Options Extension Header as a clean mechanism for signaling through the IPv6 forwarding plane without touching the control plane or exposing it to additional vulnerabilities. The Router Alert option compromises that architectural goal by allowing packets to weave in and out, between the forwarding and control planes. > > If a new protocol needs to weave in and out between the control and forwarding planes, it can do so by addressing its packets to the node whose control plane it needs to touch. This strategy has been demonstrated by RSVP-TE. Its benefits are: > > It has been deployed on the global internet (i.e., across domains) > It can be ACL'd by simply examining the destination address and next (non-IPv6) header. There is no need for the ACL mechanism to parse the HBH Options header > > I think another advantage of encoding the service, function or protocol into packets' DAs is that it would also make implementing layer 2 packet filtering of those packets easier, since the DA is in always in a fixed location in the frame, and can't be hidden behind a chain of EHs, a vulnerability that RA Guard has to deal with c.f. RFC 7113. For example, if RAs were multicast to a well-known RA specific multicast address such ("all RA receivers"), rather than the all-nodes multicast address, then RA Guard would be simpler to implement by matching on the packet's IPv6 DA and nothing else. For unicast RAs back to a individual node, a well-known RA specific IPv6 anycast address could be defined that all RA receivers listen on (although don't reply to NSes for), and then the router link-layer unicast's the RA to the individual receiving node, with the link-layer address for this anycast response having being learned using the corresponding RS's source IPv6 LLA address. The layer 2 device could then filter on this well known RA specific anycast DA. Regards, Mark. > Ron > > > Juniper Business Use Only > > ________________________________ > From: Bob Hinden <bob.hinden@gmail.com> > Sent: Tuesday, June 11, 2024 11:55 AM > To: IPv6 List <ipv6@ietf.org> > Cc: Bob Hinden <bob.hinden@gmail.com>; 6man Chairs <6man-chairs@ietf.org>; draft-bonica-6man-deprecate-router-alert@ietf.org <draft-bonica-6man-deprecate-router-alert@ietf.org> > Subject: Re: Adoption call for draft-bonica-6man-deprecate-router-alert > > [External Email. Be cautious of content] > > > Hi, > > With no hats on. > > My thoughts on deprecating Router Alert is what was written in Section 5.2.1 of the HBH Processing draft (now in RFC Editor queue): > > DISCUSSION > > The function of a Router Alert Option can result in the processing > that this specification is proposing to eliminate, that is, to > instruct a router to process the packet in the control plane. > This results in the concerns discussed in section 4. One approach > would be to deprecate this, because current usage beyond the local > network appears to be limited, and packets containing Hop-by-Hop > options are frequently dropped. Deprecation would allow current > implementations to continue and its use could be phased out over > time. > > The Router Alert Option could have a potential for use with new > functions that have to be processed in the control plane. Keeping > this as the single exception for processing in the control plane > with the following restrictions is a reasonable compromise to > allow future flexibility. These restrictions are compatible with > Section 5 of [RFC6398]. > > My question is do we want to disable the possibility of any new functions that need Router Alert in the future. > > Bob > > > > > On Jun 10, 2024, at 4:23 PM, Jen Linkova <furry13@gmail.com> wrote: > > > > This email starts 6MAN adoption call for the following document: > > > > Title : Deprecation Of The IPv6 Router Alert Option > > Authors : Ron Bonica > > Date : 2024-02-19 > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-deprecate-router-alert/__;!!NEt6yMaO-gk!CmCegd8V41HWGLJly2mqXbYx0AwGFa6dv4knJdVkLfmlQRCdNqHTUVtGQ5yfA2rqkdAZnI3aY_VTaJ06BDI$ > > > > Substantive comments, statements of support for adopting this > > document or objections to the adoption should be sent to the mailing > > list. Editorial suggestions can be sent to the authors. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: > --------------------------------------------------------------------
- [IPv6]Adoption call for draft-bonica-6man-depreca… Jen Linkova
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Joel Halpern
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Mark Smith
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Brian E Carpenter
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Ole Troan
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… xiao.min2
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Michael Richardson
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Bob Hinden
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Ron Bonica
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Brian E Carpenter
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Adrian Farrel
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Ron Bonica
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Sebastian Moeller
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Adrian Farrel
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Alexandre Petrescu
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Adrian Farrel
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Ron Bonica
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Bob Hinden
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Brian E Carpenter
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Brian E Carpenter
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Bob Hinden
- [IPv6]Re: Adoption call for draft-bonica-6man-dep… Mark Smith