Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)

Ole Troan <otroan@employees.org> Fri, 10 November 2017 21:52 UTC

Return-Path: <otroan@employees.org>
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 0604F1271DF; Fri, 10 Nov 2017 13:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 PDCKRTHSgb84; Fri, 10 Nov 2017 13:52:48 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB0C126BF3; Fri, 10 Nov 2017 13:52:48 -0800 (PST)
Received: from h.hanazo.no (dhcp-9788.meeting.ietf.org [31.133.151.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id A2A542D50AE; Fri, 10 Nov 2017 21:52:47 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C0C8E200BA764B; Sat, 11 Nov 2017 05:52:38 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <6D004D8F-2ADD-49AE-BB87-575C74F12E9E@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_998732A2-48A5-494E-99BF-8E83DD1AF107"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sat, 11 Nov 2017 05:52:37 +0800
In-Reply-To: <e7465ac9-731f-f41b-c240-f2d9fd6e3c59@si6networks.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont <fgont@si6networks.com>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org> <e7465ac9-731f-f41b-c240-f2d9fd6e3c59@si6networks.com>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TPcZILy1oPsXmHXatQTdupTmbog>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 10 Nov 2017 21:52:50 -0000

>> I think you also make a point that there are further considerations
>> here, than just the wire-format. Especially around additional state
>> in the routers. In the early days of IPv6 design a lot of time and
>> effort was made in avoiding state in the network. If this mechanism
>> made address allocation inherently less robust, I think a case could
>> be made for why the IETF should specify this in more detail.
> 
> Indeed it does:
> 
> Current SLAAC: Router crashed and reboots -> network doesn't break
> 
> This document: Router carshes and reboots -> who knows what happens.
> (Not only this protocol requires state that wasn't required for SLAAC,
> but now you also need the mappings to be maintained on stable storage.
> Otherwise, if the router crashes and reboots, the netwoks will most
> likely break).

If you read this document as an operational document, describing one potential deployment scenario, then those considerations are left as an exercise to the operator. I.e. don't deploy this in cases where this can happen.

If this has been a protocol specification, I agree that would not be acceptable.

>> I am not convinced of that though. (In my implementation per host
>> prefix adds configured state, but dramatically lessens dynamic state
>> (ND)).
> 
> What do you mean by "configured state"?
> 

In SLAAC, routers require that the IPv6 prefix is configured on the interface.
You can also implement this mechanism in that way.
It is still state, but different dynamically discovered state like the ND cache, or dynamic and non-recoverable state like what you get with middleboxes.

Best regards,
Ole