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

Fernando Gont <fgont@si6networks.com> Sun, 12 November 2017 01:54 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 766AB124BFA; Sat, 11 Nov 2017 17:54:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 XN--dakUueuP; Sat, 11 Nov 2017 17:54:01 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF819129412; Sat, 11 Nov 2017 17:54:00 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4] (unknown [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4]) (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 5E795800DD; Sun, 12 Nov 2017 02:53:56 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>
Cc: v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>, Enno Rey <erey@ernw.de>
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> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <e3c690ee-b0b0-07a0-46ec-1ed92f29a7d5@si6networks.com>
Date: Sat, 11 Nov 2017 22:49:23 -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: <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bQrWE11ag5vYfplaYsSjARbzya0>
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: Sun, 12 Nov 2017 01:54:03 -0000

On 11/10/2017 07:26 PM, Brian E Carpenter wrote:
> On 11/11/2017 09:42, 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.
> 
> I agree with that, and other versions of the same argument.

That certainly does not agree with my conception of what a protocol is,
which falls well under what was expressed on-list by Joe Touch.

If any of the FSMs that you can employ to model the protocol has
changed, you have changed the protocol.



> (That also
> answers Fernando's message directed at me, so I won't waste more bits.)
> 
> More on the philosophy side of the argument, WG Charters are a tool to
> allow the chairs and AD to control mission creep. They aren't sacred
> texts. So IMHO the real question is not whether this is strictly speaking
> a protocol extension, but whether it's a useful thing for the IETF to
> publish.

The "philosophy" of my comment is as follows:

* What is the document changes the SLAAC protocol, and maes SLAAC more
brittle: SLAAC is generaly resilient to a router rebooting, whereas,
with this protocol, it likely won't.

* There are a bunch of other aspects, from interoperability to security,
that have been ignored. The document just mentions "oh, we send the
multicasted RAs to unicast link-layer addresses" and essentially omits
way more cucial stuff, including: how do you time-out prefixes? How do
you generate them? What do you do when you don't have any more prefixes
to give away? And many others. Even if this same document/text was being
done in 6man, the protocol spec part is a half-baked protocol
specification. Even more, claiming that this *mechanism* a bcp, is quite
a bold statement when, as noted, there's *lots* that has been omitted.

* I would expect that the "beef" in a document is in what the wg ships
-- the rest is improvements. So, given that the protocol spec part of
this document was added after IETF LC, in a group that is not meant to
do Std Track documents, and given the issues mentioned above, I think
the protocol spec part in Section 4 is out of place.

* As a *side* comment/note: IPv6 automatic configuration is quite a mess
in a number of aspects (including
<https://www.ietf.org/archive/id/draft-gont-6man-slaac-dns-config-issues-01.txt>,
and
<https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-07>).
Publishing mechanism that is not even fully-specified and, even more,
flagging it as "bcp" just adds on top to that. I'd really also like to
see what's the criteria for specifying features in SLAAC and DHCPv6. For
instance... is the plan to duplicate in both as much functionality as
possible?  Or... do we just love SLAAC and will incorporate into SLAAC
everything that would make us otherwise use DHCPv6?  If there's
something available in one protocol (slaac or dhcv6) but not in the
other, and the feature is deemed as needed... should we use such
protocol or just figure out what to do to somehow implement such feature
in our belove one?  e.g. in this case, if what you want is a prefix, why
don't you use prefix delegation? And if the goal is just to isolate
nodes, set L=0 in the RAs, and so be it.

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