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

Fernando Gont <fgont@si6networks.com> Fri, 10 November 2017 21:05 UTC

Return-Path: <fgont@si6networks.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 97CDF1200CF; Fri, 10 Nov 2017 13:05:44 -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 DE1XypflPC1l; Fri, 10 Nov 2017 13:05:42 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47FC129479; Fri, 10 Nov 2017 13:05:42 -0800 (PST)
Received: from [10.234.32.137] (unknown [87.200.50.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9EFB182983; Fri, 10 Nov 2017 22:05:38 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan <otroan@employees.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
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>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <e7465ac9-731f-f41b-c240-f2d9fd6e3c59@si6networks.com>
Date: Fri, 10 Nov 2017 18:04:39 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/m2Isr1nGYLdgqKm9Oh6od6c8zEA>
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:05:44 -0000

On 11/10/2017 05:42 PM, Ole Troan wrote:
>> 1) My comment to the list was essentially arguing that this
>> document contains a protocol specification, and such part is not
>> suitable. I think it should be easy to converge on something
>> regarding this one:
>> 
>> Can anyone (you, for instance), provide a definition of what is a 
>> protocol, and the run this document through such definition and
>> figure out if it fits or it doesn't?
> 
> 
> A protocol is a system of rules that allow _two_ or more nodes to
> communicate. The protocol specifies the syntax, semantics and so on
> (1).
> 
> A protocol specification does not specify only the wire format.
> 
> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor
> its semantics. It only requires implementation change on one 'side'
> of the protocol, namely on the routers. From that perspective I think
> you can argue that this is not a protocol specification.

How do you get from this: "it only requires implementation change on one
'side' of the protocol" to this: "From that perspective I think you can
argue that this is not a protocol specification". (First sentence
acknowledges it *is* a protocol)



> 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).



> 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"?



> Interesting question.
> 
> Cheers, Ole
> 
> PS: This draft also raises some interesting IETF process issues
> around change control, oversight and how involved the working group
> should be in changes happening after the document is handed over to
> the IESG.

Indeed.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492