Re: FW: I-D Action: draft-templin-6man-dhcpv6-ndopt-07.txt

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 18 December 2018 14:28 UTC

Return-Path: <swmike@swm.pp.se>
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 BBFD91200B3 for <ipv6@ietfa.amsl.com>; Tue, 18 Dec 2018 06:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 KmohH-HbZSQw for <ipv6@ietfa.amsl.com>; Tue, 18 Dec 2018 06:28:24 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3821241F6 for <ipv6@ietf.org>; Tue, 18 Dec 2018 06:28:23 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0A0D5B1; Tue, 18 Dec 2018 15:28:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1545143301; bh=LVdhz6nPCeYy2nzvw+3GEQxKBWzIfSq4RsF9RYPkMiM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qhVUKucAJbX8gZdoSTfmcWJgUApkY7t+tiAi/UitgbMh4cEBHd+bVxVE/YHKcfklO EqOjkjHfLMzKxTxDQUjYgzPLGIbYvbTGA7dCEmWfmfJ4W9rO0fJtCGU9OQGE0k1fk8 /4WYFAZ4O9pw4SH94kbWJnscyzjXGoHQW1DxIrK8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0836EB0; Tue, 18 Dec 2018 15:28:21 +0100 (CET)
Date: Tue, 18 Dec 2018 15:28:21 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
cc: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: FW: I-D Action: draft-templin-6man-dhcpv6-ndopt-07.txt
In-Reply-To: <1e1563fbd9254224b985f5f5b64ed27f@boeing.com>
Message-ID: <alpine.DEB.2.20.1812181515410.3869@uplift.swm.pp.se>
References: <154507093237.4183.9080962434391021788@ietfa.amsl.com> <1e1563fbd9254224b985f5f5b64ed27f@boeing.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ETEa70zxXkU07U_KJ2VOkYCbux4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 18 Dec 2018 14:28:28 -0000

On Mon, 17 Dec 2018, Templin (US), Fred L wrote:

> This draft version introduces  a new method for updating clients with new configuration
> information when using the combined IPv6ND/DHCPv6 messaging service that has been
> discussed on this list.  It is based on the notion of an "unsolicited RA/Reply" from the router
> to the client. In this method, after the initial configuration exchange the router can at any
> time issue a new RA with an embedded DHCPv6 Reply message to cause the client to
> update its configuration information.
>
> This is different from DHCPv6 Reconfigure in that it is the router and not the DHCPv6
> server that initiates the update. There have been negative statements about DHCPv6
> Reconfigure on this list, so it would be interesting to hear what people think about
> this approach.
>
> Also new in this version is citation of 'draft-naveen-slaac-prefix-management'. In terms
> of a *solicited* IPv6ND-based prefix delegation service, this method would seem to
> obviate the need for any new PIO flag bits or options in the IPv6ND message. If an
> *unsolicited* PD service was needed, then that may necessitate the definition of a
> new PIO flag.
>
> Comments welcome,

I read the diff between -06 and -07 to find the two sections that were 
updated. It's an interesting approach to send an update with the same XID 
but now perhaps with much lower timers or similar. I do not know the 
DHCPv6 state machine well enough to say how this interacts with the rest 
of the DHCPv6 specifications?

I also see that the RA/PIO based way of performing PD is there.

How does this interact with the DHCPv6 PD messages that might be present 
in the same packet? What about doing DHCPv6 only for stateless and replace 
all stateful processing and put that into the "outer" RA part using PIO? 
I'd like to see that stateful is only done by one mechanism and that DHCP 
was only used for stateless information.

Thoughts?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se