Re: [IPv6] Node requirements freshness?

Timothy Winters <tim@qacafe.com> Wed, 03 January 2024 15:25 UTC

Return-Path: <tim@qacafe.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 DD08BC4887FF for <ipv6@ietfa.amsl.com>; Wed, 3 Jan 2024 07:25:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qacafe.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 9no-2u5olPwb for <ipv6@ietfa.amsl.com>; Wed, 3 Jan 2024 07:25:29 -0800 (PST)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 715FEC14F61A for <ipv6@ietf.org>; Wed, 3 Jan 2024 07:04:30 -0800 (PST)
Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-5ce2aada130so1961698a12.1 for <ipv6@ietf.org>; Wed, 03 Jan 2024 07:04:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; t=1704294270; x=1704899070; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7F9cX8qc9/B1ISWHlvBgHfwuh5Qj4U4bDHXy76K1mTQ=; b=A8svPWCAh7z/e1ICHzpnM71URAzjZEZp/Zdy8wUWFHqGOl+vc1xQ/yRoQHeAOR4+hM bJsINpemx/0SLHIGUmr43sRshuK9FGyXba1u6wfrOs7cEyNChCY0JkmEUz4C3XrFaLNi qHel9ycEuZfT5TlRCj5fgLd/PP3BTk780jGoM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704294270; x=1704899070; h=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=7F9cX8qc9/B1ISWHlvBgHfwuh5Qj4U4bDHXy76K1mTQ=; b=Bx+v41YV9KeoDI8G24SRifLUmeH3GNF3248N4tlNwye0wq1P+qeyM5yjUy5eL99YrN uAJR0zp35qEixX9+zkV1dLvwXR/eZQhUJVI/klKVhdbz8FNmiEorTHc6KIjGqdznYUVg COB4TwSunbcnu96jDgjo2DdEQRFKTPSoBQKISMmNhlo29xtO0VVq0AdMgVxD/LE0YVZo xd1VWUjJer9elMFdQ+klBYRkQoUWpFzQ3hiT6wfPkRBOxEuRwM6kEGCSfIW3LgyWna/p iC99f4XRdqevsF/2goOz863z9vgJaB+6HyWrW7rUCZrlBqW3gHcnjYqNDhksjwWSSGDj Lv6w==
X-Gm-Message-State: AOJu0Ywt1LtfiBNdc9NhmYH3cM5IbPt2gm0dyc3TWsevEs4P6u/imqwc 9FM2kq3b4V+kY5TwwxDHVuKJx6YivW+A/iLOtsrx3/zyzHLjuA==
X-Google-Smtp-Source: AGHT+IFbeCVZ+41zy4xJVxbm3Ul4I8FscetQOSVOJidYB/VDGtQQ35Q3tFgOBmAuWTGWF4Gy4dXbv5FgDTjA/p5UHX4=
X-Received: by 2002:a17:90b:3a87:b0:28b:3335:1489 with SMTP id om7-20020a17090b3a8700b0028b33351489mr5904060pjb.99.1704294270382; Wed, 03 Jan 2024 07:04:30 -0800 (PST)
MIME-Version: 1.0
References: <4f3f32c2-1823-9bb9-80ec-3774ed5fb448@gmail.com> <91919057-168C-46D3-91E4-3DE78B455CFD@jisc.ac.uk>
In-Reply-To: <91919057-168C-46D3-91E4-3DE78B455CFD@jisc.ac.uk>
From: Timothy Winters <tim@qacafe.com>
Date: Wed, 03 Jan 2024 10:04:19 -0500
Message-ID: <CAJgLMKuzEDHVWOkBV+JLg3R13a6nu5T9_ZaDYarjV0pYLiFeLQ@mail.gmail.com>
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "john.loughney@gmail.com" <john.loughney@gmail.com>, 6man <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000944afc060e0beef4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/R6owxBleyspyESXcXaGmZOZUayI>
Subject: Re: [IPv6] Node requirements freshness?
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: Wed, 03 Jan 2024 15:25:34 -0000

Hi Tim,

I remember the discussion about making this living document and still think
it's good idea.  I'd be happy to use the github 6MAN location for updating
the document (https://github.com/orgs/ietf-6man/repositories) as the
location.  When the time is right we could push periodic new IPv6 node
requirements.

It looks like the years between versions have been 2006, 2011, and 2019.
So I would say putting out a version in 2024 is probably a good idea.  I'm
happy to work again on this Tim C.

~Tim

On Wed, Jan 3, 2024 at 1:41 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

> Hi Brian,
>
> > On 3 Jan 2024, at 02:03, Brian E Carpenter <brian.e.carpenter@gmail.com>
> wrote:
> >
> > A comment over on v6ops prompted me to wonder how many IPv6-related RFCs
> have been published since the last revision of Node Requirements (RFC 8504).
>
> I guess that was me.
>
> > The answer is a bit scary - see list below, based on RFC number, not on
> dates.
> >
> > The source is
> https://github.com/becarpenter/book6/blob/main/20.%20Further%20Reading/RFC%20bibliography.md
>
> We did discuss at the time of RFC8504 making the draft a “living document”
> with periodic RFC publications.  Perhaps we should have done that.
>
> If the WG feels it’s timely, I’d be happy to help pull another update
> together.  I’ve explicitly copied TimW and John.  And maybe this time we
> could GitHub it and keep an up-to-date md draft, something to consider.
>
> Best wishes,
> Tim
>
> >
> > Regards
> >   Brian Carpenter
> >
> > Normative:
> >
> > RFC8505: Registration Extensions for IPv6 over Low-Power Wireless
> Personal Area Network (6LoWPAN) Neighbor Discovery
> > RFC8638: IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks
> > RFC8676: YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires
> > RFC8691: Basic Support for IPv6 Networks Operating Outside the Context
> of a Basic Service Set over IEEE Std 802.11
> > RFC8754: IPv6 Segment Routing Header (SRH)
> > RFC8781: Discovering PREF64 in Router Advertisements
> > RFC8883: ICMPv6 Errors for Discarding Packets Due to Processing Limits
> > RFC8925: IPv6-Only Preferred Option for DHCPv4
> > RFC8929: IPv6 Backbone Router
> > RFC8930: On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network
> > RFC8931: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
> Selective Fragment Recovery
> > RFC8950: Advertising IPv4 Network Layer Reachability Information (NLRI)
> with an IPv6 Next Hop
> > RFC8956: Dissemination of Flow Specification Rules for IPv6
> > RFC8981: Temporary Address Extensions for Stateless Address
> Autoconfiguration in IPv6
> > RFC8983: Internet Key Exchange Protocol Version 2 (IKEv2) Notification
> Status Types for IPv4/IPv6 Coexistence
> > RFC8986: Segment Routing over IPv6 (SRv6) Network Programming
> > RFC9008: Using RPI Option Type, Routing Header for Source Routes, and
> IPv6-in-IPv6 Encapsulation in the RPL Data Plane
> > RFC9034: Packet Delivery Deadline Time in the Routing Header for IPv6
> over Low-Power Wireless Personal Area Networks (6LoWPANs)
> > RFC9131: Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries
> on First-Hop Routers
> > RFC9159: IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet
> Protocol Support Profile (IPSP)
> > RFC9164: Concise Binary Object Representation (CBOR) Tags for IPv4 and
> IPv6 Addresses and Prefixes
> > RFC9252: BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)
> > RFC9259: Operations, Administration, and Maintenance (OAM) in Segment
> Routing over IPv6 (SRv6)
> > RFC9343: IPv6 Application of the Alternate-Marking Method
> > RFC9352: IS-IS Extensions to Support Segment Routing over the IPv6 Data
> Plane
> > RFC9354: Transmission of IPv6 Packets over Power Line Communication
> (PLC) Networks
> > RFC9428: Transmission of IPv6 Packets over Near Field Communication
> > RFC9486: IPv6 Options for In Situ Operations, Administration, and
> Maintenance (IOAM)
> > RFC9487: Export of Segment Routing over IPv6 Information in IP Flow
> Information Export (IPFIX)
> > RFC9513: OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)
> > RFC9514: Border Gateway Protocol - Link State (BGP-LS) Extensions for
> Segment Routing over IPv6 (SRv6)
> >
> > RFC9096 (BCP234): Improving the Reaction of Customer Edge Routers to
> IPv6 Renumbering Events
> >
> > Informational:
> >
> > RFC8585: Requirements for IPv6 Customer Edge Routers to Support
> IPv4-as-a-Service
> > RFC8678: Enterprise Multihoming using Provider-Assigned IPv6 Addresses
> without Network Prefix Translation: Requirements and Solutions
> > RFC8683: Additional Deployment Guidelines for NAT64/464XLAT in Operator
> and Enterprise Networks
> > RFC8978: Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to
> Flash-Renumbering Events
> > RFC8992: Autonomic IPv6 Edge Prefix Management in Large-Scale Networks
> > RFC9030: An Architecture for IPv6 over the Time-Slotted Channel Hopping
> Mode of IEEE 802.15.4 (6TiSCH)
> > RFC9098: Operational Implications of IPv6 Packets with Extension Headers
> > RFC9099: Operational Security Considerations for IPv6 Networks
> > RFC9288: Recommendations on the Filtering of IPv6 Packets Containing
> IPv6 Extension Headers at Transit Routers
> > RFC9313: Pros and Cons of IPv6 Transition Technologies for
> IPv4-as-a-Service (IPv4aaS)
> > RFC9365: IPv6 Wireless Access in Vehicular Environments (IPWAVE):
> Problem Statement and Use Cases
> > RFC9386: IPv6 Deployment Status
> > RFC9433: Segment Routing over IPv6 for the Mobile User Plane
> > RFC9453: Applicability and Use Cases for IPv6 over Networks of
> Resource-constrained Nodes (6lo)
> >
> > Experimental:
> >
> > RFC8885: Proxy Mobile IPv6 Extensions for Distributed Mobility Management
> > RFC9229: IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol
> > RFC9268: IPv6 Minimum Path MTU Hop-by-Hop Option
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>