Re: [IPv6] Node requirements freshness?

Bob Hinden <bob.hinden@gmail.com> Wed, 03 January 2024 18:44 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 4F372C14F6A3 for <ipv6@ietfa.amsl.com>; Wed, 3 Jan 2024 10:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.104
X-Spam-Level:
X-Spam-Status: No, score=-6.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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=ham 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 KDZKT_iljn7j for <ipv6@ietfa.amsl.com>; Wed, 3 Jan 2024 10:44:42 -0800 (PST)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) (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 CCC74C14F6A2 for <ipv6@ietf.org>; Wed, 3 Jan 2024 10:44:42 -0800 (PST)
Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-5efb0e180f0so44295507b3.1 for <ipv6@ietf.org>; Wed, 03 Jan 2024 10:44:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704307481; x=1704912281; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=VoQeXyXbdPBKC3V5jwuPqS6E06Z0WZUiD3fD1WL9Cgo=; b=NUt5OzPQhID41cQhVXzB21yiFLJ8fuAuuPkII51N+YgPQkqkQ8dVO8gXepiyDeHxlh cZyQljGEyTA07qeZCQVQceqIr8u0dVFyU41uGdJgGft/9QdpzQ0q/8H/UpvR9Gyq5Dsb r5f6YalsGOlBrPL6R0/eOcnAQBq9TLsDyplyY2HflitHczV7X5K7IA7wTuVV7mzk6R0g CfnXCPN3t2c0tk4iPdR44geFHKFeyYHRiyv06JObNxECnI+FzB1VCX+UPopEpYdcW2F4 qrqeT4UhfHM9qr/UNdajhv1suavoYEYkQA5p81SGD3XMku7+zVwIAep80sLx3MDx7fSw cw8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704307481; x=1704912281; 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=VoQeXyXbdPBKC3V5jwuPqS6E06Z0WZUiD3fD1WL9Cgo=; b=bb0i261MS3n15BkPAmEs7SuYGaZtEsVqRz7e3uMNCvyK0wuo29N5y+zG1rOIwYxbLd 5z3csfTzuK8uPsM2M7wzzEDQLm2WZp74+SiDGXrhSnQuYob3FAxFnkfWs6V5vCOfzxAf LGw/FF9LVRXgWi9tcVhXOhVY9thm0WeOmL2clM7Ds04qtfuZHp4ucTcrNdcQD9Zk0Vyu R4fMDoC4ImiY4yXfgAYonxfI8Z+il1c0e8CRt7/CQDSfDnmOMRnjZh86NhScBXpdbFmW yejOE6ZKJ9+UK53HDXaBte0mQK/XFl9+KUznO/7nNw4mBHHKjuA+m9QW82d+m6/OVuyh z0aQ==
X-Gm-Message-State: AOJu0Yz0tu0S0Il0xNnzpFT42BnHWOCN312K9iDDCpk+m183tzQHKLqh CjhKOQMP432FQ90DYWZAF9U=
X-Google-Smtp-Source: AGHT+IFTUbhWsxHqREKZ//Eq72xad6akqwnMGDGvFu5nbdJjt2awrzK/7ej/gFLCedKVFL+83MbSOw==
X-Received: by 2002:a81:5bd7:0:b0:5d7:1940:dd86 with SMTP id p206-20020a815bd7000000b005d71940dd86mr14461889ywb.92.1704307481458; Wed, 03 Jan 2024 10:44:41 -0800 (PST)
Received: from smtpclient.apple (99-31-208-116.lightspeed.sntcca.sbcglobal.net. [99.31.208.116]) by smtp.gmail.com with ESMTPSA id n39-20020a81af27000000b005eeafe4f70csm6964631ywh.57.2024.01.03.10.44.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2024 10:44:41 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <C77EDDC8-936B-4813-A779-9186E3DAAB1E@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F1FA786-D2C1-4CFC-8791-B5508FFB0D90"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Date: Wed, 03 Jan 2024 10:44:30 -0800
In-Reply-To: <CAJgLMKuzEDHVWOkBV+JLg3R13a6nu5T9_ZaDYarjV0pYLiFeLQ@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>, John Loughney <john.loughney@gmail.com>
To: Timothy Winters <tim@qacafe.com>, Tim Chown <Tim.Chown@jisc.ac.uk>
References: <4f3f32c2-1823-9bb9-80ec-3774ed5fb448@gmail.com> <91919057-168C-46D3-91E4-3DE78B455CFD@jisc.ac.uk> <CAJgLMKuzEDHVWOkBV+JLg3R13a6nu5T9_ZaDYarjV0pYLiFeLQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BUbjNnC2uOi3jrDApXHBBkuvMmI>
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 18:44:47 -0000

Tim, Tim,

> On Jan 3, 2024, at 7:04 AM, Timothy Winters <tim@qacafe.com> wrote:
> 
> 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.

I think this is a good idea and agree given the number of potential changes (Brian’s list of RFCs), doing it in 2024 makes sense.

The challenge will be, of course, to not spend all of the time on a few reoccurring issues that I don’t need to list.

Bob


> 
> ~Tim
> 
> On Wed, Jan 3, 2024 at 1:41 AM Tim Chown <Tim.Chown@jisc.ac.uk <mailto:Tim.Chown@jisc.ac.uk>> wrote:
>> Hi Brian,
>> 
>> > On 3 Jan 2024, at 02:03, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto: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 <mailto:ipv6@ietf.org>
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------