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

Erik Nordmark <nordmark@acm.org> Mon, 13 November 2017 02:08 UTC

Return-Path: <nordmark@acm.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 C486912785F; Sun, 12 Nov 2017 18:08:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 4wwzq_MxPsZt; Sun, 12 Nov 2017 18:07:59 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A1C126CB6; Sun, 12 Nov 2017 18:07:56 -0800 (PST)
Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAD27cHn005676 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Nov 2017 18:07:40 -0800
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: DY Kim <dykim6@gmail.com>, Fernando Gont <fgont@si6networks.com>
Cc: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" <v6ops-ads@ietf.org>, Ted Lemon <mellon@fugue.com>, draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <BBB987EF-D91C-4FD1-9084-21382F24E7BF@gmail.com> <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com> <A790D1BF-A617-4256-9633-E9A5FB77537A@gmail.com> <203d7ede-2169-4a04-e545-2eb48144eac3@si6networks.com> <0045136C-91FA-4B31-91E0-D2D44E7433AB@gmail.com>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <17184d11-ece0-38c4-3d94-af2972deb7cd@acm.org>
Date: Mon, 13 Nov 2017 10:07:37 +0800
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: <0045136C-91FA-4B31-91E0-D2D44E7433AB@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Sonic-CAuth: UmFuZG9tSVbzTx8m5OB22l3criAqsrHSwLIAU179eze9HPlHellPqITck2lZxYTU4oinLVKJ7h+3F13JM7V6oIPVykQrSKUN
X-Sonic-ID: C;6GlpbBfI5xGlQIlQ3iMJ6w== M;BHVabRfI5xGlQIlQ3iMJ6w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2m7b9hz8vXnmdt92aJe4C-T5sYw>
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:08:03 -0000

On 11/11/2017 11:54 AM, DY Kim wrote:
> The ‘state’ in the wording SLAAC means that of the host, I mean.

DY,

The history of why SLAAC has "stateless" in its name in its name doesn't 
match your statement.
When SLAAC was created there was BOOTP/DHCP for IPv4, but not work had 
started on what would later become DHCPv6, but such work was 
anticipated. The use of "stateless" was to distinguish SLAAC from the 
case where there is a network service (akin to DHCP) which retains state 
about the allocations made for hosts. At that time the use of DHCPv4 for 
IPv4 address allocation was quite new and not very robust and there was 
concerns about IPv6 having a hard dependency on such a service.

Also, further back in time, at the Big10 meeting of the IPng directorate 
was the first time I heard the 128 bit address format be discussed with 
the idea than an IPv6 address could be formed using (a) prefix(es) 
advertised by the router and a 48 byte mac address of the host following 
an approach which had been used in other protocols (IPX I believe).

The fact that as IPv6 then evolved that evolved from 48 byte MAC to 64 
bit IID and the IID's later became more friendly to privacy 
considerations doesn't change the fact that we have never added a 
requirement that routers speaking SLAAC maintain per-host allocation 
information; they do maintain per-link configuration information.


Whether the split in to stateless and stateful (aka DHCPv6) address 
allocation was a wise choice is something I leave as an exercise to the 
reader. I merely offer the observation that we keep on muddling any 
boundaries between stateless and stateful address allocation and also 
between address allocation and host configuration.
The resulting larger number of possible implementation and configuration 
choices on the host and network/router side doesn't seem helpful in 
facilitating interoperable protocols.

Regards,
    Erik


> 
> SLAAC don’t need to require the router to do anything special, other than the router’s usual prefix advertisement through an RA.
> 
> The same is true of the case wherein DHCP is used to assign addresses to hosts by the router.
> 
> How the router keeps the link prefix info in its system is an interest neither to DHCP or SLAAC, since the link prefix itself is not about address assignment in which DHCP and SLAAC are interested.
> 
> How the router keeps the link prefix(es), whether shared or unique to each hosts, is an issue of the router system implementation, not of the protocols DHCP or SLAAC.
> 
> Hence, the question about how the prefix(es) are stored or recovered should be addressed to the router spec, neither to DHCP, nor to SLAAC, nor to this draft, I’d think.
> 
> ---
> DY
> 
>> On 11 Nov 2017, at 12:16, Fernando Gont <fgont@si6networks.com> wrote:
>>
>> On 11/11/2017 12:13 AM, DY Kim wrote:
>>> The host’s state.
>>>
>>> RFC 4862:
>>>
>>>   "This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6).”
>>>
>>>   "The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers."
>>
>> Host state, maintained at the router?
>>
>>
>> -- 
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>