Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

Bob Hinden <bob.hinden@gmail.com> Fri, 26 June 2020 23:35 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 831C13A0D16 for <ipv6@ietfa.amsl.com>; Fri, 26 Jun 2020 16:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz_dtZovy0z2 for <ipv6@ietfa.amsl.com>; Fri, 26 Jun 2020 16:35:29 -0700 (PDT)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06D33A0D14 for <ipv6@ietf.org>; Fri, 26 Jun 2020 16:35:29 -0700 (PDT)
Received: by mail-pj1-x1035.google.com with SMTP id h22so5584790pjf.1 for <ipv6@ietf.org>; Fri, 26 Jun 2020 16:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=0TEP7br3v+Ok6iCaV/viqZ1sRJyjYdLvTNugN6Ekhig=; b=HEeCRygEdBeyKHGom+uzq7b4uK8zOj7YIVlcZz2riD9vYcU7BtPkhsG9ZkOCL5YbSK f88F5z2UioUR1F13p6iqldYNAY79lCN6wHBkt++fKGp1J554ic69FK4LRT8CFSrX/dop nXTSydaye5WL6MiRzdAorwQj58L95Qwt52NrCgfeEjf3aONQDMbXJ2TxfozswtfRpV5W FO0a+YKgrUEcCfYlJHHsIA+1L/7+lsFUB/EGbnDKfK8dtrCLhEA1bR9iAue5gKf/vI8o WaNfj7Zbl8N/gjDByTWv+wtvxnFRPwNaAGYlyskwetwKpzUuGu7YqztmA1NhBtPuO2B+ tuDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=0TEP7br3v+Ok6iCaV/viqZ1sRJyjYdLvTNugN6Ekhig=; b=UMiJJ+/pzA6LjrtDkZzPdcYBDxavEMbKuEMuO92dLuvF/olXmUtgQIFMeJ275D/YV2 Z2mT/K2e3skVJDuRjinw/NUf9wMoJAxlUe2wjdhfcLsLKlwfq6YJas8IKvXhzevmpFtv UeTjpVNFkdaij4uiIHID8mmqW3owm/Groosw+Q+MTVHNTroNrPHb6bUrhAiphY94dyTT fDxj6LFU7h/whv1amR0SNTHt54JaDStjjpZzdykYtXLxrJbbeWbxP0zkKQw2kMC1vZVi Dk2zeSQbZqTcJp7moNLCEBp2F7K/reu2uvZgMe92dLXy7xeYcH/zxk/hYns4eAjHm8SR vvDw==
X-Gm-Message-State: AOAM532LBn3tiywfsPV6v6C5vNu+7PNHNI008MvBOLAzYHf8D/GOuCvM VQldlUS1xwDQ3yQQmmmcGg9mlECvN7M=
X-Google-Smtp-Source: ABdhPJzj6VnMhcdMzZJ5aHK7KKbdweMWd9RR9iNFF0Vd9l2j9ZZflBLbkJzIfIRyLTrVkdBOWccgig==
X-Received: by 2002:a17:90a:e801:: with SMTP id i1mr5741251pjy.79.1593214528929; Fri, 26 Jun 2020 16:35:28 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:75ad:bcf5:ab6c:b402? ([2601:647:5a00:ef0b:75ad:bcf5:ab6c:b402]) by smtp.gmail.com with ESMTPSA id j8sm12045439pji.3.2020.06.26.16.35.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 16:35:28 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CEDCEA08-8AED-4CEA-949B-CE5514A254E2"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Subject: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
Message-Id: <CC295D49-5981-41C3-B4DB-E064D66616CE@gmail.com>
Date: Fri, 26 Jun 2020 16:35:27 -0700
Cc: Bob Hinden <bob.hinden@gmail.com>, Ole Trøan <otroan@employees.org>
To: IPv6 List <ipv6@ietf.org>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YBnHoe9yqw0Five6ckAjDWgMpyE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 26 Jun 2020 23:35:32 -0000

This message starts a two week 6MAN call on adopting:

 Title:          Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events
 Authors:        F. Gont, J. Zorz, R. Patterson
 File Name:      draft-gont-6man-slaac-renum-08
 Document date:  2020-05-18

 https://tools.ietf.org/html/draft-gont-6man-slaac-renum

as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on 10 July 2020.

There has been a lot of discussion on this draft, the chairs have some concerns with this document being adopted, but wanted the w.g. to express its opinion.  Our concerns include:

This document proposes significant changes to SLAAC to fix what could be seen as an implementation problem in some edge routers.  This will affect all IPv6 nodes, not only the ones communicating with these edge routers.  This part of IPv6 is a mature standard.   It is not clear we should modify all IPv6 hosts to deal with one corner case that may break other things allowed by the standard.

The changes proposed will make SLAAC more active, the changes include:

 o Reducing the default Valid Lifetime and Preferred Lifetime of PIOs
 o Caps the received Valid Lifetime and Preferred Lifetime of PIOs.
 o Frequent retransmission of configuration information
 o Routers send all options in RA messages

Some additional questions for the w.g. to consider:
 o Are there better approaches to address the underlying issue?
 o Do the proposed changes work in all deployments?
 o Are some proposed changes worth advancing even if the entirety may not be? If so, which ones?

We would like the w.g. to consider and comment on these issues when responding to this adoption call.

Bob & Ole
6man co-chairs