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

DY Kim <> Tue, 14 November 2017 08:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32DA31292FD; Tue, 14 Nov 2017 00:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 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] 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 cwkfRoV6Xtpl; Tue, 14 Nov 2017 00:34:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6D3A1292C5; Tue, 14 Nov 2017 00:34:34 -0800 (PST)
Received: by with SMTP id y5so14816508pgq.7; Tue, 14 Nov 2017 00:34:34 -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=9uzRtcuqIv3lEn5NTCdkXU1F+lBtWz4zEGKufCU5Q3U=; b=MZek7yKcaE2Y9xGMR6SmWQeSmSIyMHITBz1+a8ZS7NmG5iXpWovqjZb1Iq0DYIV2WB c+PeCq2M+UY7X9PZHfgOY4heGva+PpUfCDjKqTGEQ0a+1cuwmTxC5et0XiGUEoIkiwmv svCwIjTzkhSWijW9umuwriFFAPOOoVJYVkVQzYmdjoJjWK3Wg8Suq3eQgtXDEb8LpQHL rEGQM4w81JA3wnpZj0hDFpbo6GpwtcyqPVDBLnE9ULuK2RBGe7AQKgvauDOlFGDCdyLS IplW6Egd5+o4uBe7FOPVliQh2E7R/EeZSLJLEGbcBgQMVa2DpHhMBRoNxH/2YtvosIpc ky5Q==
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=9uzRtcuqIv3lEn5NTCdkXU1F+lBtWz4zEGKufCU5Q3U=; b=BFRk9neMgUcmdKE9HbMhPgf0dpfircxxaeLQ6nMtXHWkzLXn5viJZQMJjfFL/p77WT +BqKOXI4IMJvGR12qAc9G7DcMwg0CJRVMzxT9gVkzxbwUPPfUpvL14xVjCbXubmXQuvr uRJ5pWY7Anc3/rUuqVX30y7LmCgWmzHok67G4Nhyma6fhHxe7Z3fEejhx+78ZcM0goTr 21VdxoTH787QTQqoBiHHfETr00jqPJw5ySi8YnVjnGNGiMEx8ev3ZPBnuITU3DxEsdP3 ObZqE0tW3/JinN1RYQ2K2G3KAb486ownMPtxO67Y/dNUd7c8tuIu4RTSPFCekRAEtUVW a4Xg==
X-Gm-Message-State: AJaThX7rjsHFStXO5OVlqITVoxBtvnAcrqCSAdiYqqk4BnNZU+2/gRJy xLJlniO0pLK36gLWYhn3TGkN4vYZ
X-Google-Smtp-Source: AGs4zMaw0/H9rHIFNbiZ4Y6yr25JZ7ijkWmX6F81mywL18a1vKmH7H2ndC4nhgC0r0y0iJfX6UgFWg==
X-Received: by with SMTP id v32mr11838069plb.175.1510648473685; Tue, 14 Nov 2017 00:34:33 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id u8sm28221689pgp.17.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 00:34:32 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim <>
In-Reply-To: <>
Date: Tue, 14 Nov 2017 17:34:29 +0900
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <d86e4678-7634> <> <> <> <> <>
To: " WG" <>
X-Mailer: Apple Mail (2.3445.4.7)
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: Tue, 14 Nov 2017 08:34:36 -0000

Apology to James. My message is not meant to be directed against James message.


> On 14 Nov 2017, at 11:59, DY Kim <> wrote:
> With my self torn between two schools of thought, I might retry the following argument:
>  ‘The draft doesn’t make SLAAC stateful’
> The essence of my argument is that what the draft brings new to the router side is not any change of states of any protocols but rather implementation details that need not be reflected on existing protocols like SLAAC or NDv6.
> The rationale for my argument goes like the followings:
> 1.	As far as the hosts are concerned, nothing changes. A host receives RAs as usual, not even knowing that the prefix provided is unique per host, hence running DAD as usual.
> 2.1.	As for the router, take the case of usual SLAAC. There are no code lines specific about SLAAC. They just issue RAs, either in response to RSs or unsolicited. All it does is either set L=1 or L=0, in accordance with the operators policy.
> 2.2.	Let us see what changes are taking place to the router as a consequence of this draft.
> 	First of all, the router intended to implement the ideas of this draft should already know that it’s going to deal with different prefixes for different hosts, uniquely per host. Any routers of the intention then surely have to write in codes to manage the table of prefix-to-host mapping. 
> 	Should there be any changes to the specs of NDv6 (rfc4861) that the router is running? No. (can be confirmed by re-reading NDv6). NDv6 is silent about how to store/manage the prefix it has handed out, anyhow. That part is implementation details that a protocol need not / should not bother itself with.
> 	Should any part of the specs of SLAAC (rfc4862) be changed? No. (can be confirmed by re-reading SLAAC). The router hasn’t been involved with any SLAAC specific behaviors anyhow in the fist place, all it does in connection with prefix assignment are NDv6-related actions, which puts us back to the statements made in the just preceding paragraph.
> 3.	Anything new this draft has brought are not spec changes (of either SLAAC or NDv6) but operational recommendations for any routers intending to adopt the ideas described in the draft. Certainly, you might have to rewrite part of your router software, but the necessary rewriting is such that you put more care about database management in regard to prefix-to-host mappings, but is not of such consequential quality that you might have to ask 6man to revise either SLAAC or NDv6.
> 4.	The conclusion is that the draft has not made any changes to SLAAC. The management of the prefix-to-host mapping table is not part of the SLAAC specs itself, but is simply part of your implementation details up to your best choice in your system environment.
> P.S.: A protocol, by definition, is an interaction between two remote entities by exchange of messages of specific syntax and semantics. If there are no changes to such incurred, it’s not a protocol changes, and so is not subject to be sent to 6man.
> ---
> DY
>> On 14 Nov 2017, at 10:49, james woodyatt <> wrote:
>> On Nov 13, 2017, at 17:40, Ted Lemon <> wrote:
>>> Also, it is not true that there is no pushback when new options are proposed for RA.
>> I have a pile of rejections, none of which were duplicates of DHCPv6. One of them was eventually obsoleted by PCP. Another probably gets replaced by a mess of security vulnerabilities (but at least ND6 will remain pure!).
>> --james woodyatt <>
>> _______________________________________________
>> v6ops mailing list