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

Brian E Carpenter <> Mon, 13 November 2017 05:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AF0B129478; Sun, 12 Nov 2017 21:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oprL18inJqBJ; Sun, 12 Nov 2017 21:50:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 006CC127599; Sun, 12 Nov 2017 21:50:01 -0800 (PST)
Received: by with SMTP id f187so8002023itb.1; Sun, 12 Nov 2017 21:50:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mGSHCHyc5YYpiPx2zpW/MBlwTG5vgyVWMkcQzbpYd40=; b=tFSH/i9hnuN9arhJgmrgzFuJsh7iuM+oOO0JBPlp84XrdvHpxMiVrgpNtSFfevevBr FJfydXOD7O4wbNo5S6fKBPSfnClenAKRsmtfzVldc6MFj7OLdkbYk8XEoa9B4VMTcf8Y XwQy3DFkAC+04Jxiufuv99B0GT8Ka1I9RbFvU6c0TjifK+ngGyC+zSAoySG28dTauCX1 E4feapYLLQrmgHkmAaxOJtctDz7v/fBC5SSaCeiLmq1ji6oyvG2/5fEFY9CD+3nZFFRR L+oM3zc+mPspioh6ccApBSysoAc8oWlkNshbekuTLjD3QNv2a3xn5s9V0wfDZaRDpbgr A60Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=mGSHCHyc5YYpiPx2zpW/MBlwTG5vgyVWMkcQzbpYd40=; b=pZ8S4wh9RGwDYgozzF9oVxaS+dY9oPmOP4MAbaQyxleM62CiFjbdzw3eWRRFmROZ5t bvMCgNQ0E/0XLbA2OZy9E6H7K279JbZD0rJ7Zq9lv8pI5naZBLBXlnuGfplMAjXM3GYH OYMkmLEq1m51pgxmQaVpobh+nWPra/W+KgqcSDsG+nhjTLQ6Dnz2B559mvdCOj/x0yoI UQOg+pnlxcqkdvAW8iQ7UTuvaMpksUtS6wCBQBVEuv4GnRWg7/tSdLZwqkWCTXwQfw0M 6RqfrHypxTUYa6K1sdTehWBtToTjrxByTEPy5Z85pDH516k/0t25dhx9UExQWC3RWJCF vdOQ==
X-Gm-Message-State: AJaThX4lJ0e2SE4nYtuzAwfE8TKgHk8Fl1tHUV07GoOznzoiJkfp1aGP 3nHpqZlpPl/2qoG8wCC5AcDyviU4
X-Google-Smtp-Source: AGs4zMYAVAJkt8oNumRU/iL5aeadaaOda6VxLePQLyH0GnPjqSj53knAP4B/3MKZ9Cw2N/xTI1uowQ==
X-Received: by with SMTP id c22mr9957122itb.102.1510552201304; Sun, 12 Nov 2017 21:50:01 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by with ESMTPSA id u140sm3708052itc.41.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 21:50:00 -0800 (PST)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Erik Nordmark <>, DY Kim <>, Fernando Gont <>
Cc: IPv6 Operations <>, "" <>, "" <>, "" <>,
References: <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Mon, 13 Nov 2017 18:49:58 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Nov 2017 05:50:04 -0000

On 13/11/2017 15:07, Erik Nordmark wrote:
> 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, 

To be 100% historically accurate, DHCP was defined but definitely
unproven; the vast majority of sites were still configuring host
IP addresses by hand. The commercial alternatives such as Netware
were all better than IP in that respect, and SLAAC looked like
a great leap forward.


> 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 <> 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:
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> Administrative Requests:
>> --------------------------------------------------------------------
> _______________________________________________
> v6ops mailing list