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

Ole Troan <otroan@employees.org> Mon, 13 November 2017 03:15 UTC

Return-Path: <otroan@employees.org>
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 65A5C127077; Sun, 12 Nov 2017 19:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 u02-sxvPWJti; Sun, 12 Nov 2017 19:14:58 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C351712700F; Sun, 12 Nov 2017 19:14:58 -0800 (PST)
Received: from h.hanazo.no (nat64-ad.meeting.ietf.org [31.130.238.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 3C85E2D5038; Mon, 13 Nov 2017 03:14:58 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D3EE6200BEA860; Mon, 13 Nov 2017 11:14:30 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <581AF3E8-00D9-4EBD-A98A-2D5867010980@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_4282AA4E-DEA8-472C-A8A4-925C0B0244D2"; protocol="application/pgp-signature"; micalg=pgp-sha512
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)
Date: Mon, 13 Nov 2017 11:14:29 +0800
In-Reply-To: <862687c9-c107-53a8-288a-29049097b0e1@acm.org>
Cc: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>, Joe Touch <touch@strayalpha.com>
To: Erik Nordmark <nordmark@acm.org>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com> <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <CAKD1Yr26NK2osApYZBm8Yd=0X7xcetrxojp6=JHOEAu9BB0q8A@mail.gmail.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org> <862687c9-c107-53a8-288a-29049097b0e1@acm.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pfuRzTTZ7bSCkqaUcj4jaLSOFno>
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: Mon, 13 Nov 2017 03:15:00 -0000

Erik,

>> Or do as I do in my implementation.
>> Model each host as being on it's own point to point interface.
>> Configure the IPv6 prefix on that interface. That configured state is exactly like what we have in classic SLAAC.
> 
> Ole,
> 
> did you figure out how to expire those allocated prefixes when the host is long gone from the network?
> 
> The draft seems to be silent on that issue and if the purpose is to document some current practice it would be good to capture that.

Right, and it might be a case of "it depends".
Interesting question though, would be benefit from an L3 solution to this problem?

In my implementation, since I'm only doing a data-plane, it's not my problem. Let the control plane deal with that. ;-)

- in a wired network, where routing is done to the edge, with a physical interface to each host then data-link layer events would suffice.
- on 802.11 you could be tightly integrated with AP / WLC

If we were to do this at L3, we would need some sort of keepalive messages.
Thinking aloud here, any time where a host requires state to be maintained in the network, we are much better off if we put the burden of maintaining that state and ensuring the state is in the first-hop router on the host. E.g. like you did with the ARO option.

Cheers,
Ole