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

DY Kim <dykim6@gmail.com> Thu, 09 November 2017 00:16 UTC

Return-Path: <dykim6@gmail.com>
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 7B371129420; Wed, 8 Nov 2017 16:16:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Cn9TBJRPL8nG; Wed, 8 Nov 2017 16:16:39 -0800 (PST)
Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 8066912943A; Wed, 8 Nov 2017 16:16:19 -0800 (PST)
Received: by mail-pg0-x243.google.com with SMTP id a192so3245116pge.9; Wed, 08 Nov 2017 16:16:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e6jPrhQNubWhREfu7WrT+PHb1wYlQkCijJb1k5HHIws=; b=EDIhBAJl6cyQUc+L41vPC/t6AjXnyigjpaxg25rfZL7653JHsDb8/Xgi+DxjR6Sc6y c0pbgCBiffSYysLRhkjcV8Vw9DNrwFl8zxm2E6bc1UNlkahl/dQqSLQgZQ5MSjNcswOG 2rV0A5ob7FpyLsGov44oe5pgUh7WfARRvH8JoAFIG/gSWm311wU5UJPknMdlMQRP6Kvc vyBV9E4LlUbraSuyrxWcWjrbOavHqIz27T7vZed3EbhsZJ2y+T6eI0Qb7mDORjO/ZFLE 1BBGZweL6pV1Pj/ZOw/R/waiBbLuGO/KXRPS4+kVOMVOTPSMTtGteewCe3aWgMLHVvbZ vlZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e6jPrhQNubWhREfu7WrT+PHb1wYlQkCijJb1k5HHIws=; b=SAqbU/y+n21eI3PdpWAQZzVGvkj3PTUVGQFmffvtCcpGXRZr6BDSH3funpR1q9aW9r xh1cltvZROFrG2TlDVjWBTYOAeL44RwL9k6kzsrlF9tDnS9IJtOLyxJeE5ol/NT11vFU yTBtZioTFrlc2C5tSon/0mSnOSEQlUZZeJi9Dt2GWilSZNMw10e1VQLJW0QTCZjjGy/s ap+PpyUUFtJWA13qsdtmxWlP9ugVMDU8kOeElaN7AZgsx3trgUluIq+bOpDDuQDEubKr 6gFrymI0H0GLf16wJja/z5zzPl7vjQ1pc2ZxSsuWX9bryQX8iM6HQgCBOa70hp7KIUYh aY0w==
X-Gm-Message-State: AJaThX6ap7RYSnzSjV/AoTf4wqw1jX/1CBmoVcbrqiCTtVSVaKt+A2V8 pPVUmU4R3uSYU39Yme9e16M=
X-Google-Smtp-Source: ABhQp+RtxLIgASwV9swNjG90ajJedlrk8y5wnMwNd/j0tZ7lLzjZ11wRWqBOHCcYdoZ3R0d3FKzP3w==
X-Received: by 10.98.60.211 with SMTP id b80mr2248532pfk.4.1510186578968; Wed, 08 Nov 2017 16:16:18 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id 125sm9541756pff.14.2017.11.08.16.16.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 16:16:17 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim <dykim6@gmail.com>
In-Reply-To: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com>
Date: Thu, 9 Nov 2017 09:16:12 +0900
Cc: IPv6 Operations <v6ops@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" <v6ops-ads@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2EDAAEF-2F2B-4160-8D72-24941E81F1EC@gmail.com>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_jboMuNqhOnHfSq3wOM6aballno>
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: Thu, 09 Nov 2017 00:16:41 -0000

Hi Fernando,

If I’m not wrong, SLAAC in this document is one supposed to run on hosts not on the router…

---
DY

> On 7 Nov 2017, at 06:13, Fernando Gont <fgont@si6networks.com>; wrote:
> 
> Folks,
> 
> These past few days I ended up reviewing the aforementioned document, as
> a result of a thread on this document on the v6ops mailing-list.
> 
> I had reviewed an early version of the document, in which the benefits
> of not having and on-link prefix were discussed -- which was certainly
> fine (and I supported).
> 
> While reviewing this document a few days ago, I found that Section 4
> (page 5) contains what is a protocol spec, rather than an operational
> BCP. It contains rules regarding how to set the link-layer address (to a
> unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
> now remember which prefix has been "leased" to which node -- something
> that seems to be way outside of the v6ops charter, and that should have
> been done in 6man, instead.
> 
> Looking at diffs, it seems this additional text was incorporated very
> recently, in version -09 of the I-D, published in mid September
> (<https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt>).
> It seems to be that this change is way beyond what the authors
> originally proposed
> (a bcp saying that it's great to give each host a unique prefix, without
> providing details on specific mechanisms or doing protocol specs --
> which was obviously within v6ops' charter), and what the wg shipped, and
> also seems to be in conflict of the v6ops and 6man charters (v6ops
> doesn't do protocol specs, but this document certainly contains one).
> 
> Besides what seems to be a conflict in the aforementioned charter, there
> are a number of issues associated with the specified protocol:
> 
> 1) The protocol spec specified in this document requires the SLAAC
> router to keep state of the "leased" prefixes -- what seems a major
> change to SLAAC, which now would be kind of as stateful as DHCPv6.
> 
> 2) There are scenarios in which multiple nodes might receive the same
> packet -- say a NIC let's the packet through because it is in
> promiscuous mode -- wich could possibly lead to two nodes configuring
> the same prefix.
> 
> 3) What happens if the SLAAC router crashes and reboots, loosing state
> of the "leased" prefixes?
> 
> 4) How are prefixes selected? And, what's the minimum size of the pool
> of prefixes for the selection algorithm not to break due two "prefix
> collisions"? Does the selection algorithm have any specific properties?
> 
> 
> In summary, revision -09 (most likely done to address some DISCUSS)
> turned the original BCP document into a protocol spec, with a major
> change to SLAAC, which should have happened in 6man, rather than in
> v6ops (which is not allowed to do protocol specs). Looking at the
> current document (to be published), Section 4 (page 5) looks more like a
> Std Track document than a BCP.
> 
> It was suggested to me that I discuss this on the mailing-list... hence
> this post.
> 
> Thoughts?
> 
> P.S.: I wished I had caught this earlier. I just didn't.
> 
> Thanks,
> -- 
> 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
> --------------------------------------------------------------------