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

Ole Troan <otroan@employees.org> Mon, 13 November 2017 03:07 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 3E102127876; Sun, 12 Nov 2017 19:07:32 -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 TOgnc0W6tZaj; Sun, 12 Nov 2017 19:07:30 -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 928BE1274D0; Sun, 12 Nov 2017 19:07:30 -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 E3CFE2D4F99; Mon, 13 Nov 2017 03:07:29 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3987A200BE9B01; Mon, 13 Nov 2017 11:07:02 +0800 (+08)
From: Ole Troan <otroan@employees.org>
Message-Id: <BBAB48C0-384B-4380-9359-7965C7C61D58@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_C6067886-6048-43A9-9270-02E99B3343BA"; 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:07:01 +0800
In-Reply-To: <e7ec4633-8d45-1cff-ce37-48dafd488e13@si6networks.com>
Cc: Lorenzo Colitti <lorenzo@google.com>, Joe Touch <touch@strayalpha.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont <fgont@si6networks.com>
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> <e7ec4633-8d45-1cff-ce37-48dafd488e13@si6networks.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zvmoRSsLc9OrvSfv407Kk93DPTY>
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:07:32 -0000

Fernando,

>> 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.
> 
> The I assume that, in that case, you don't need to do anything fancy
> with how you send the multicasted RAs, and the SLAAC router
> implementation need not keep a table of bindings?

That's correct.
The interfaces look like:
interface P2P-Ethernet0 remote-mac aa:bb:cc:dd:ee:ff
 ipv6 address 2001:db8::1/64

Think of it as an interface with a fixed L2 address for the remote end.
L3 to L2 address mapping is then fixed, both for unicast and multicast.
Should that have it's own internet draft, very possibly?

In the vein of all problems in computer science can be solved with another layer of redirection.
How these interfaces are created and how they are maintained across reboots etc, can be considered out of scope for the SLAAC feature.
Although they have to be solved somewhere somehow of course.

Best regards,
Ole