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

Ole Troan <otroan@employees.org> Mon, 13 November 2017 02:43 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 DC2BA128C84; Sun, 12 Nov 2017 18:43:42 -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 PAZel7X3j8NQ; Sun, 12 Nov 2017 18:43:41 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD121287A3; Sun, 12 Nov 2017 18:43:23 -0800 (PST)
Received: from h.hanazo.no (nat64-ad.meeting.ietf.org [31.130.238.173]) (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 E23192D4F99; Mon, 13 Nov 2017 02:43:22 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 28D7E200BE74BD; Mon, 13 Nov 2017 10:42:55 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_7B5AE5A5-DD9C-4E8B-B371-F90B7BD64889"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 10:42:54 +0800
In-Reply-To: <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, Joe Touch <touch@strayalpha.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "v6ops@ietf.org WG" <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> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com> <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <CAKD1Yr26NK2osApYZBm8Yd=0X7xcetrxojp6=JHOEAu9BB0q8A@mail.gmail.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vRMAYZ6lYzQAgu_Bfp85xHGyZSo>
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: Mon, 13 Nov 2017 02:43:43 -0000

Fernando,

>> <mailto:touch@strayalpha.com>> wrote:
>> 
>>    FWIW, I would agree with that if this were an issue of WG focus creep.
>>    AFAICT, the issue appears to go much deeper, which means it's an Area
>>    boundary issue if it is indeed a protocol extension.
>> 
>>    IMO, OPS stays in the lane of suggesting sets of *existing* protocol
>>    parameters and features, or indicates where MAYs and SHOULDs can be
>>    relaxed (or not) - all of this remains compliant with the protocol.
>>    Changes to the protocol should not be considered operational decisions,
>>    again IMO.
>> 
>> 
>> Excuse me, but I really cannot fathom why we are saying that this draft
>> defines a new protocol
> 
> Model SLAAC with a FSM for the client, and a FSM for the server. Now
> apply this document. And look at the SLAAC router FSM.
> 
> Did it change (and quite a lot, actually)?  If yes, then you ahve
> changed the protocol. If not, you didn't do the FSM properly.

Or do as I do in my implementation.
Model each host as being on it's own point to point interface.
Configure the IPv6 prefix on that interface. That configured state is exactly like what we have in classic SLAAC.

Ole