IETF Logo Mail Archive

Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Jan Zorz - Go6 <jan@go6.si> Fri, 22 February 2019 20:37 UTC

Return-Path: <jan@go6.si>
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 D7966130E5F for <ipv6@ietfa.amsl.com>; Fri, 22 Feb 2019 12:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 uzKrRIOSFtz2 for <ipv6@ietfa.amsl.com>; Fri, 22 Feb 2019 12:37:02 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [91.239.96.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58C7130E66 for <ipv6@ietf.org>; Fri, 22 Feb 2019 12:37:01 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 6319C660DC for <ipv6@ietf.org>; Fri, 22 Feb 2019 21:36:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id iA8O6EkMwmC7 for <ipv6@ietf.org>; Fri, 22 Feb 2019 21:36:56 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id 511E46005F for <ipv6@ietf.org>; Fri, 22 Feb 2019 21:36:56 +0100 (CET)
Received: from haktar.local (unknown [IPv6:2001:67c:27e4:5::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 323DF80DED for <ipv6@ietf.org>; Fri, 22 Feb 2019 21:36:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1550867815; bh=O6EPOkP7eyhaUOaISO7UYp8bW0YFNcD0vSf64r58Co4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rzUOgbZaX4UB7wthx43g3VtmlO+j/wp92d6pyJHzwrq0dG0XdBmjW1D2YitXbwbr+ U745vx9n8X2Bl7IPz1DuDEMS49GNAqVRNqqBia+ygiXh4MXbHWJ+6lTEvDOkhfcwF6 qW2Jdk+lQk8Ge5AJeKbiOPMDG+CpdJKmoHvubunU=
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <CAFU7BAS1_veTu-ZXAF0MF4niJwz149nGipx3ep_6fh1bewOzgg@mail.gmail.com> <d9503983-6524-a13a-2cb0-cdcb95f76ea6@si6networks.com> <CAFU7BAQfg712UfgW9wi9pd3eVeZP9cqJEXd6=FDmchuSdauv+g@mail.gmail.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <CAFU7BASDgmSwY=SLiabSqyiTOphxU0COtFLQvT8drm0iTxM+-Q@mail.gmail.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com> <CAAedzxq5d0fgOq5KZu7aCL9wxoDij6C-1Ad9+nQbYyhu2aMt-Q@mail.gmail.com> <da1c6391-5e69-f09b-dee5-83d25f1cd8cd@si6networks.com> <CAAedzxouCqcmW0rA6KwDZEO-n5yVZUYHc+GSetJ8O7=Liou4tA@mail.gmail.com> <0DDB4538-62F8-442A-A12C-D3C176540884@jisc.ac.uk> <a0a4246c-24cd-905c-4cde-0428b83ba5a3@si6networks.com> <CAOSSMjVtOXOOCHVvofsMQH5=bjV_tupqCKed6C4fXiS_ZnCSQg@mail.gmail.com> <eaea9418-cd5d-714f-9332-8b7de49d5d8b@si6networks.com> <90dd7fee-77cc-3411-7079-60a6edf488d9@gmail.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <29b2f8fb-f75f-a9e6-b0a2-5651fa2a6427@go6.si>
Date: Sat, 23 Feb 2019 00:36:53 +0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <90dd7fee-77cc-3411-7079-60a6edf488d9@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/al0OkmmIMSI7v80XaPEzeLhmPg8>
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, 22 Feb 2019 20:37:03 -0000

On 21/02/2019 22:14, Brian E Carpenter wrote:
> Of course, SHOULD means "that there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed...". In other words, do RFC8028 and Rule 5.5
> unless there's a good reason not to.

Unfortunately not all vendors understand SHOULD in this way. 
Implementing more options is expensive and lowers the profits, so it's 
quite easy to fall into "implement all the MUSTS, declare compliancy 
with RFCs and ship the product" trap.

Cheers, Jan

v2.23.0 | Report a Bug | By Email