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

Nick Hilliard <nick@foobar.org> Mon, 13 November 2017 15:36 UTC

Return-Path: <nick@foobar.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 08B51127843; Mon, 13 Nov 2017 07:36:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SLR-x1TNTanA; Mon, 13 Nov 2017 07:36:38 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166E81294EF; Mon, 13 Nov 2017 07:36:34 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vADEaLep022965 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2017 14:36:23 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5A09BBFE.5050407@foobar.org>
Date: Mon, 13 Nov 2017 15:36:30 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Victor Kuarsingh <victor@jvknet.com>
CC: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
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> <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org> <e7ec4633-8d45-1cff-ce37-48dafd488e13@si6networks.com> <BBAB48C0-384B-4380-9359-7965C7C61D58@employees.org> <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com> <CAJc3aaPZ2dxJ7JSz07wEE6TCqwRyGv=wSQmQ3Wci-L_3uix9_w@mail.gmail.com> <d3a874b6-5353-d3dd-a87f-9fe4aa1fe3aa@si6networks.com> <CAJc3aaOVVpJ11-2VYzn=VEziVy3j+8wdVziP0Kfo5=7w4Z6ePw@mail.gmail.com>
In-Reply-To: <CAJc3aaOVVpJ11-2VYzn=VEziVy3j+8wdVziP0Kfo5=7w4Z6ePw@mail.gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/cjKXspNran5F1LWmfQJCrJ2Rb7k>
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 15:36:41 -0000

Victor Kuarsingh wrote:
> It was noted "From a operational point of view, one would wonder why
> pursue this path as opposed to e.g. do DHCPv6".
> 
> What I am suggesting is the draft represents an actual operational
> point of view from people in the field.
> 
> However, the methods described don't inhibit other choices to be made
> in other networks, with perhaps other circumstances, to use DHCPv6.

I'm in favour of publication of this document, but not as-is. The change
in the SLAAC protocol to being stateful needs to be explicitly
acknowledged in the document, because it has substantive operational
implications for the router issuing the RAs, for other edge devices
which are involved in the host device SAVI process and for the host
device itself.

Nick