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

Ole Troan <otroan@employees.org> Fri, 10 November 2017 20:42 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 23B76124B17; Fri, 10 Nov 2017 12:42:46 -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 bMtXcB9ciYbD; Fri, 10 Nov 2017 12:42:44 -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 650F7126B7E; Fri, 10 Nov 2017 12:42:44 -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 6FE6F2D5038; Fri, 10 Nov 2017 20:42:43 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 05913200B94A31; Sat, 11 Nov 2017 04:42:32 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_616D6661-8BF3-4E15-8C22-5D96CE71EF16"; 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 04:42:31 +0800
In-Reply-To: <ea772bfd-4004-7f94-8469-b50e3aff0f29@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>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dd8f0Dx1DldgCAsA6KI5mxvBar4>
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 20:42:46 -0000

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

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.
I am not convinced of that though. (In my implementation per host prefix adds configured state, but dramatically lessens dynamic state (ND)).

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.

1:Freely borrowed from wikipedia.