From apak at ripe.net Tue Aug 2 13:26:02 2022 From: apak at ripe.net (Anastasiya Pak) Date: Tue, 2 Aug 2022 13:26:02 +0200 (CEST) Subject: [ipv6-wg] New on RIPE Labs: Deploying IPv6-Mostly Access Networks Message-ID: <372280375.8338.1659439562969.JavaMail.app-admin@ba-apps-3.ripe.net> Dear colleagues, Dual stack is the most common way of deploying IPv6 in access networks. A recent standard defines IPv6-mostly access networks, providing IPv4 connectivity only for legacy devices while allowing modern devices to run IPv6-only. My colleague Ond?ej Caletka explored the deployment of IPv6-Mostly Access Networks. Read his article on RIPE Labs: https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-networks/ Best regards, Anastasiya Pak Marketing & Communications Officer RIPE NCC From fgont at si6networks.com Fri Aug 19 04:59:33 2022 From: fgont at si6networks.com (Fernando Gont) Date: Thu, 18 Aug 2022 23:59:33 -0300 Subject: [ipv6-wg] Fwd: RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers In-Reply-To: <20220818232147.B5B991527E1@rfcpa.amsl.com> References: <20220818232147.B5B991527E1@rfcpa.amsl.com> Message-ID: Hi, FYI. RFC 9288, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers" (available at: https://www.rfc-editor.org/rfc/rfc9288) FWIW, IMO most of the value is in the analysis of what protocols/features use what EHs, and what would break (if anything) if packets with EHs are dropped. These other two are useful for context: * RFC 9098, "Operational Implications of IPv6 Packets with Extension Headers" (https://www.rfc-editor.org/rfc/rfc9098.html) * RFC 7872, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World (https://www.rfc-editor.org/rfc/rfc7872.html). Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers Date: Thu, 18 Aug 2022 16:21:47 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: rfc-editor at rfc-editor.org, drafts-update-ref at iana.org, opsec at ietf.org A new Request for Comments is now available in online RFC libraries. RFC 9288 Title: Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers Author: F. Gont, W. Liu Status: Informational Stream: IETF Date: August 2022 Mailbox: fgont at si6networks.com, liushucheng at huawei.com Pages: 33 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsec-ipv6-eh-filtering-10.txt URL: https://www.rfc-editor.org/info/rfc9288 DOI: 10.17487/RFC9288 This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From sander at steffann.nl Fri Aug 19 19:06:48 2022 From: sander at steffann.nl (Sander Steffann) Date: Fri, 19 Aug 2022 18:06:48 +0100 Subject: [ipv6-wg] RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers In-Reply-To: References: <20220818232147.B5B991527E1@rfcpa.amsl.com> Message-ID: <6BB35313-818E-4ACC-977D-9963FCF0567C@steffann.nl> Hi Fernando, > FYI. RFC 9288, "Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers" (available at: https://www.rfc-editor.org/rfc/rfc9288) Thank you for keeping up the good work! Cheers, Sander From fgont at si6networks.com Wed Aug 31 12:34:32 2022 From: fgont at si6networks.com (Fernando Gont) Date: Wed, 31 Aug 2022 07:34:32 -0300 Subject: [ipv6-wg] Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum) Message-ID: <8392459f-7b05-a1b3-554c-bcfb8b0424d1@si6networks.com> Folks, We have been discussing the potential problems associated with SLAAC renumbering events for a while now -- one of the most common cases being ISPs rotating home prefixes, and your devices ending up with stale/invalid addresses. We have done quite a bit of work already: * Problem statement: https://datatracker.ietf.org/doc/html/rfc8978 * CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096 But there's still some work to do to address this issue: The last remaining it is to improve SLAAC such that hosts can more gracefully deal with this renumbering events. In that light, IETF's 6man has been working on this document: https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt And we have proposed a simple algorithm for SLAAC (an extension, if you wish) that can easily help, as follows: If you (host) receive an RA that contains options, but not all of the previously-received options/information, simply send a unicast RS to the local-router, to verify/refresh that such missing information is still valid. If the information is stale, get rid of it. I presented this algorithm at the last IETF meeting (https://youtu.be/eKEizC8xhhM?t=1308). (You may find the slides here: https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improving-the-robustness-of-stateless-address-autoconfiguration-slaac-to-flash-renumbering-events-00) Finally, I've sent draft text for the specification of the algorithm here: https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/ We would be super thankful if you could take a look at the draft text (i.e., https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) and provide feedback/comments. If you can post/comment on the 6man wg mailing list (https://www.ietf.org/mailman/listinfo/ipv6), that?d be fabulous. But we'll appreciate your feedback off-line, on this list, etc. (that'd still be great ;-) ) Thanks in advance! Regards, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 From vasilenko.eduard at huawei.com Wed Aug 31 14:11:27 2022 From: vasilenko.eduard at huawei.com (Vasilenko Eduard) Date: Wed, 31 Aug 2022 12:11:27 +0000 Subject: [ipv6-wg] Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum) In-Reply-To: <8392459f-7b05-a1b3-554c-bcfb8b0424d1@si6networks.com> References: <8392459f-7b05-a1b3-554c-bcfb8b0424d1@si6networks.com> Message-ID: <9779b41a5a5240209625b01ea3dd8802@huawei.com> Hi all, The router could split information between RAs (and send it at different intervals). It may be difficult to guess what is stale and what is just "not in this RA". Fernando proposing (not documented yet in draft-ietf-6man-slaac-renum-04) re-asking the router by RS and using timers (size of timers is not proposed yet) To guess that router has probably supplied the full set of information And we could start concluding what is stale. There is an alternative proposal to signal by ND flag that "this RA has the complete set of information" https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02 ... then you could make your reliable conclusion on what is stale. IMHO: Clear signaling that "information is complete in this RA" is better than guessing by timers. It is the more robust solution. If you have an opinion on this matter, Please send a message to ipv6 at ietf.org Thanks. Eduard -----Original Message----- From: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] On Behalf Of Fernando Gont Sent: Wednesday, August 31, 2022 1:35 PM To: ipv6-wg at ripe.net Subject: [ipv6-wg] Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum) Folks, We have been discussing the potential problems associated with SLAAC renumbering events for a while now -- one of the most common cases being ISPs rotating home prefixes, and your devices ending up with stale/invalid addresses. We have done quite a bit of work already: * Problem statement: https://datatracker.ietf.org/doc/html/rfc8978 * CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096 But there's still some work to do to address this issue: The last remaining it is to improve SLAAC such that hosts can more gracefully deal with this renumbering events. In that light, IETF's 6man has been working on this document: https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt And we have proposed a simple algorithm for SLAAC (an extension, if you wish) that can easily help, as follows: If you (host) receive an RA that contains options, but not all of the previously-received options/information, simply send a unicast RS to the local-router, to verify/refresh that such missing information is still valid. If the information is stale, get rid of it. I presented this algorithm at the last IETF meeting (https://youtu.be/eKEizC8xhhM?t=1308). (You may find the slides here: https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improving-the-robustness-of-stateless-address-autoconfiguration-slaac-to-flash-renumbering-events-00) Finally, I've sent draft text for the specification of the algorithm here: https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/ We would be super thankful if you could take a look at the draft text (i.e., https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) and provide feedback/comments. If you can post/comment on the 6man wg mailing list (https://www.ietf.org/mailman/listinfo/ipv6), that?d be fabulous. But we'll appreciate your feedback off-line, on this list, etc. (that'd still be great ;-) ) Thanks in advance! Regards, -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ipv6-wg