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

DY Kim <> Tue, 14 November 2017 02:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C8331292FD; Mon, 13 Nov 2017 18:59:38 -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 02QqxG4Mp7wg; Mon, 13 Nov 2017 18:59:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E16B91286B1; Mon, 13 Nov 2017 18:59:36 -0800 (PST)
Received: by with SMTP id l24so914180pfj.6; Mon, 13 Nov 2017 18:59:36 -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=EiiNgQRKMpSo0wB4UTz2sbBiUpiBAynBDeAed2gjjdA=; b=KQuUecQ3wGh9ALxZ0rLEbUKc6E1YnMCvC4MMIuhyo825+EgdhN2kijk4p3yCIZJIC7 U2QyczR9ga+jSBWijBif8y1F7aTUktVK75xZvPFSsqh64CdEuiK1E9RXqg82lNj7xJAR bpeoeFKqDJej3hQXuiPenaUn5J67YPzqpOgvWdSgzndhdn8Zd6qc5OjEWRcVbPZ6pmsy drCCp1Jw6IEo2rBKWSX5tl4x33v5FHnjFPHL3Uh4+KWsJLndlfqeJbUvORmS+T3b8Bft ieQfnMDWjiKVtGFxV2khD4cpr7n5naNPBVRQ81sIGasEYk1/hbZ2oFdNwcabZ2Z0YKa8 aoAg==
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=EiiNgQRKMpSo0wB4UTz2sbBiUpiBAynBDeAed2gjjdA=; b=hiYolI6kjkzptMR/agpNRgLpWicd0Tlm9TmBzI3x+7F3BbYIicd9FNMxb84hOqP1oJ oDqRPi5laeqmWFYF2aFS+3TeX2KI5G+IfUKb2+klM2rCmCyudBvjgqCWdpHp258Ozjth dtV/I6i7Hh4a9S/s4rM23iAHS52px56eprIUX1uowv78/L+EQ4nmgznTFsydEgD9D0uI df2Q8qqsPtf/tOgg9C3zqlx3HlbMKi0MNsjU0lcrYJKSTUkS3pFadFG7yUByRKehbyuc uui5Gb7GxghSHaxHv+QWBmEISQnGRbJMS88FKSujJGdYXB3GURsVYMYsaU2BQoOyPJAM fTSg==
X-Gm-Message-State: AJaThX5PrOqS2/6Oa+IWbmbLTUxi9AM8+/SDKAaimz0R3N5VLht+5bEm DSHdUpP1XaIunR0p1nliJEF1aXii
X-Google-Smtp-Source: AGs4zMaXNyXPViAh46P6FFbEwU2Y/PvrOegnhVvGBMuDLYSRYmrefHGa+YPmIv5/11uU8TZ77j2Mcg==
X-Received: by with SMTP id h6mr10739695pgp.144.1510628375909; Mon, 13 Nov 2017 18:59:35 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id r1sm12041903pfe.99.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 18:59:34 -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 11:59:32 +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 02:59:38 -0000

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.


> 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