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

DaeYoung KIM <> Mon, 13 November 2017 04:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7996124B0A; Sun, 12 Nov 2017 20:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c-xoroPaKi4h; Sun, 12 Nov 2017 20:38:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCA941270A7; Sun, 12 Nov 2017 20:38:09 -0800 (PST)
Received: by with SMTP id q4so2893519pfg.13; Sun, 12 Nov 2017 20:38:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vqWepG3+a1KmPnlEmvxLtazIHUJWLyfUcMsxaDAtsA4=; b=Ef7oCNQ5QxjTWuWS6GgOTf4o1XwjSJGN57IVzRgDfm6gowmke+Y5kXjQiDJA4kGSAT sOK3MDFlCnXaBFF4I+Aycr6TKuIWpdiVWcouBEhWX7wVmyfb0CBDmIEA5QefJtodALK4 xuErYwP4qIwg4YmigZfp946As9Auq23xrKdMvwckVyBhjeh7qHAzqwHv2xrofpAFAhxP j4WxUDky5WDgbZuycqTiK5lbiNYRLGTuX/uYuzcslDfLgaa+RZFxiW3JvPcyfmfTY1RC fJ803xaxUHFuczB5TzLoUEkBnZRmH32CNnqXJplky0u40Zm3hOTJJs37tGmdp5QECBkf GshQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vqWepG3+a1KmPnlEmvxLtazIHUJWLyfUcMsxaDAtsA4=; b=TmCqipiHItzAw4Nf9T879LPB8uA0MihPzbfQvHSTuBYAji2KEmnGEXLR8EFQwIQyWs /zSlTWpToNrJ993ebI32w0+nxm79VEOU5iG1vv0o/0Rd5Z174yrOYTnx9hmYPkATPqEr qQDNP9vimt3CoCi/q6NxagSSUDC0H9KmrNMlXbtutHgmNRQdXwcO58E0MtnyAKZCl5ak uthQVMyS8EX36VmNuk6Bhr8wStkjnm2jG/TuPM8xf1DnCBenvd3vxu+2IZqMTW3dTwD5 KYrWSxateQs45Wmg+Sc6EQRSlvAuxoPPj1khe6wVGi5emrKKYaKEqY2OsAqxnuVp6Gq0 fcSA==
X-Gm-Message-State: AJaThX6V9KkfZ7eNKeBo3kUHCxp2apYKNhkbwW1y23CwOlT8T6v5sgJH QiIcUP+RZKIeFqnI3mTB6/M=
X-Google-Smtp-Source: AGs4zMaT516fJT8WJn/gFjf5q3QFjVe8L37spxG6YsbNreMkileWWWDQp+dS2ZFheciH+fzOgwqQDw==
X-Received: by with SMTP id y2mr8595904pfl.150.1510547889298; Sun, 12 Nov 2017 20:38:09 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id f70sm22324908pfc.84.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 20:38:08 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DaeYoung KIM <>
X-Mailer: iPhone Mail (15B150)
In-Reply-To: <>
Date: Mon, 13 Nov 2017 13:38:05 +0900
Cc: Fernando Gont <>, IPv6 Operations <>, "" <>, "" <>, "" <>, Ted Lemon <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Erik Nordmark <>
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 04:38:12 -0000

Thanks, Erik. Well taken.

Sent from my iPhone

> On 13 Nov 2017, at 11: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, 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:
>> --------------------------------------------------------------------