From fgont at si6networks.com Sun Jul 7 13:22:40 2019 From: fgont at si6networks.com (Fernando Gont) Date: Sun, 7 Jul 2019 12:22:40 +0100 Subject: [ipv6-wg] IPv6 SLAAC renum/problems IETF I-D (Fwd: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt) In-Reply-To: <156242875288.15242.14064012489544905957.idtracker@ietfa.amsl.com> References: <156242875288.15242.14064012489544905957.idtracker@ietfa.amsl.com> Message-ID: Folks, To make the story short: Based on the recent discussion we had on our IETF I-D draft-gont-6man-slaac-renum, we have posted this new I-D which focuses on discussing the problem, and describing operational mitigations. The document is available at: https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt Comments are welcome. It is being discussed on the IETF v6ops wg mailing-list: https://mailarchive.ietf.org/arch/msg/v6ops/5D2hdpB6QHRm9u-MUj6erQaLZY0 If possible, post your comments on the v6ops wg list. But comments are welcome, whether there, here, or even unicast to us (co-authors) ;-) Thanks! Cheers, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-slaac-renum-00.txt Date: Sat, 06 Jul 2019 08:59:12 -0700 From: internet-drafts at ietf.org To: Fernando Gont , Jan Zorz , Richard Patterson A new version of I-D, draft-gont-v6ops-slaac-renum-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-slaac-renum Revision: 00 Title: Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events Document date: 2019-07-06 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-slaac-renum-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-slaac-renum/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-v6ops-slaac-renum Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and discusses operational workarounds to improve network robustness. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From raymond.jetten at elisa.fi Tue Jul 30 11:28:58 2019 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Tue, 30 Jul 2019 09:28:58 +0000 Subject: [ipv6-wg] RIPE 79 IPv6 Working group Message-ID: Hello All, The RIPE 79 meeting will take place will take place in Rotterdam Netherlands from 14-18 October 2019. https://ripe79.ripe.net/ The IPv6 WG session will most likely be on Thursday Morning. (still subject to change). Would you like to present at our WG session, and have a subject that would be of interest on IPv6, or develop IPv6 related RIPE policies, have useful recommendations, or plan other documents that will help the deployment of IPv6 ? We, the IPv6 WG co-chairs, would like to invite you to submit your presentation proposals, including a brief description of the content and the time you would need. Please send them directly to us: ipv6-wg-chairs at ripe.net . Once we start to make the final agenda, we will let you know if you are selected or not. Please be aware of the following: Due to potential technical issues, presenters/panelists should be physically present at the RIPE Meeting. RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. All sessions will be recorded and broadcasted, and will be publicly available afterwards, so make sure you own the copyrights of all content. See you in Rotterdam, Jen, Benedikt, Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: