Re: [IPv6] Node requirements freshness?

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 03 January 2024 19:21 UTC

Return-Path: <brian.e.carpenter@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 60642C14F6FE for <ipv6@ietfa.amsl.com>; Wed, 3 Jan 2024 11:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Level:
X-Spam-Status: No, score=-2.197 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, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 svipz55KQaTe for <ipv6@ietfa.amsl.com>; Wed, 3 Jan 2024 11:21:17 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 3B72CC14F6BA for <ipv6@ietf.org>; Wed, 3 Jan 2024 11:21:17 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1d3f2985425so41801575ad.3 for <ipv6@ietf.org>; Wed, 03 Jan 2024 11:21:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704309676; x=1704914476; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0Pn+XJ7WpYLrxRf6JzbXahTUnyHx5tKzOWWslTvrWDo=; b=Jix3ySmQza4uE1eMFmdrEy4g7l5j16fK9JfebVLkYiTCLdn1lprsRmebE8Z6gvRwDF fyNE0Rsr/1+eBjHkwJ5ywXzl+HggE7EVjEn1eREFqakPfAtoGSqpwDYPAcVKim5sjAAJ WgAiUGq6S8uqvG0VkSada+sYX6ZZZwb2vQByu3lMB7fUhavJf2Fg4rtu7Jo30brJYehM /x1aNIy8cOnagRsAKknvTynG59jq3NYsjfQ5aFET+AG5eNfDoGI69wSXabVqd2wji1KR Mam72b7x6/KHwDEniJpdm8d9bjoJ+YVxmO8e11q3cGNImaS59TxwCYG95js+jBxHgvgn Iezw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704309676; x=1704914476; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0Pn+XJ7WpYLrxRf6JzbXahTUnyHx5tKzOWWslTvrWDo=; b=A7z+xUq2C1yg3F7Kk/5Vv740LR1vhiEszlo6fQuDve8j/JzsjDL/MFBaTW5y4iF3n5 89MNV45ZcNHhS2yUJhWyP3SWghdl1CRMqiXwQHHJ3KOfpVZ5JH0qWR4I9UWsPFlAIAFa +dt6AKzj654KTvTkmwnLOBW0lc8XHBSq3/wUIcK6bHhil78oe7K/YuljH3x+jlKUi/Ut xxUWde9Jqy7GSFOJa261SBbWWYYkQrJgFe6e/3i3qpa1oN6H6qC8rZpRVIWSEpkkpt14 BxWPtKXFTbUIDFO8LdqgUJk/LvPUG+oc7W0OwlgqiVzU6m6dqxTJQGSOBxoqxp8X3usd fzdw==
X-Gm-Message-State: AOJu0YwuJ1CeAnrpQabId0kSMWJG88GYzLvn7811xsiHzEMRd7O1bv6k 4e4TM9idpR4KmXmM8TU+RFs=
X-Google-Smtp-Source: AGHT+IGQ4EpsAPM5gw7zX4u48VBB63HDMVnRyeHYjAKSQhIp3lSMNFRhCEavvKApNVWrrGg0kZHyjQ==
X-Received: by 2002:a17:902:8f81:b0:1d3:948d:2282 with SMTP id z1-20020a1709028f8100b001d3948d2282mr8695970plo.12.1704309676318; Wed, 03 Jan 2024 11:21:16 -0800 (PST)
Received: from ?IPV6:2404:4400:541d:a600:44b7:2c2e:2bc6:8707? ([2404:4400:541d:a600:44b7:2c2e:2bc6:8707]) by smtp.gmail.com with ESMTPSA id z3-20020a170903018300b001cfa718039bsm24115893plg.216.2024.01.03.11.21.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jan 2024 11:21:16 -0800 (PST)
Message-ID: <ae51f889-626d-feaf-c769-6d0f8bd60373@gmail.com>
Date: Thu, 04 Jan 2024 08:21:12 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Timothy Winters <tim@qacafe.com>, Bob Hinden <bob.hinden@gmail.com>
Cc: John Loughney <john.loughney@gmail.com>, IPv6 List <ipv6@ietf.org>
References: <4f3f32c2-1823-9bb9-80ec-3774ed5fb448@gmail.com> <91919057-168C-46D3-91E4-3DE78B455CFD@jisc.ac.uk> <CAJgLMKuzEDHVWOkBV+JLg3R13a6nu5T9_ZaDYarjV0pYLiFeLQ@mail.gmail.com> <C77EDDC8-936B-4813-A779-9186E3DAAB1E@gmail.com> <CAJgLMKsgz-SLBu=hUJ9h13TQkaCVA8yHuYq5xdnkehAPqdfUpQ@mail.gmail.com> <BF7C5F75-9AAD-4DAE-B204-3C98AE66D113@gmail.com> <CAJgLMKsB_YNh7FicF_6ECELfA1_Hofaph4kXUSGZpVKSGcGtMw@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CAJgLMKsB_YNh7FicF_6ECELfA1_Hofaph4kXUSGZpVKSGcGtMw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NYqikOKvsGFqvoSX17zQ-ZExWMk>
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 19:21:19 -0000

On 04-Jan-24 08:01, Timothy Winters wrote:
> Hi Bob,
> 
> Those are wise words we should probably adhere to.

Agreed. I think there might be a case for adding an "Open Issues" appendix, listing without discussion the points where there is no consensus.

Also at this stage in history, would it be worth adding a "No Longer Recommended" appendix, listing techniques that are either formally obsolete, or not much use any more?

    Brian

> 
> ~Tim
> 
> On Wed, Jan 3, 2024 at 1:58 PM Bob Hinden <bob.hinden@gmail.com <mailto:bob.hinden@gmail.com>> wrote:
> 
>     Tim,
> 
>     Perhaps the focus of the work should be to add things where there is an agreed IETF consensus documented in a published RFC.
> 
>     Bob
> 
> 
> 
>>     On Jan 3, 2024, at 10:55 AM, Timothy Winters <tim@qacafe.com <mailto:tim@qacafe.com>> wrote:
>>
>>     Hi Bob,
>>
>>     That has always been the challenge with this document.  We'll try to get something up for IETF 119.
>>
>>     I look forward to putting on my hard hat for the SLAAC/DHCPv6 discussion. :)
>>
>>     ~Tim
>>
>>     On Wed, Jan 3, 2024 at 1:44 PM Bob Hinden <bob.hinden@gmail.com <mailto:bob.hinden@gmail.com>> wrote:
>>
>>         Tim, Tim,
>>
>>>         On Jan 3, 2024, at 7:04 AM, Timothy Winters <tim@qacafe.com <mailto: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 <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 <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 <https://www.ietf.org/mailman/listinfo/ipv6>
>>>             > --------------------------------------------------------------------
>>>
>>>         --------------------------------------------------------------------
>>>         IETF IPv6 working group mailing list
>>>         ipv6@ietf.org <mailto:ipv6@ietf.org>
>>>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <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
> --------------------------------------------------------------------