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

Erik Nordmark <nordmark@acm.org> Mon, 13 November 2017 06:24 UTC

Return-Path: <nordmark@acm.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 D78A0129471; Sun, 12 Nov 2017 22:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 OQWX4IF6GZhI; Sun, 12 Nov 2017 22:24:58 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 9033F12946F; Sun, 12 Nov 2017 22:24:58 -0800 (PST)
Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAD6OnX1001057 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Nov 2017 22:24:50 -0800
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan <otroan@employees.org>, Erik Nordmark <nordmark@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>
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> <581AF3E8-00D9-4EBD-A98A-2D5867010980@employees.org>
From: Erik Nordmark <nordmark@acm.org>
Message-ID: <2a4d3627-77b8-f1b0-9d49-344ff2ea83fe@acm.org>
Date: Mon, 13 Nov 2017 14:24:47 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <581AF3E8-00D9-4EBD-A98A-2D5867010980@employees.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVYsYCMrugIgQGivyPfprIAON8OUXetjpfVAGEt6zN2FX+Gj8+LViwA/XR5pQi2OKYUvi+8t9YQuLhENYQ37aZxu
X-Sonic-ID: C;+GulWTvI5xG9d4lQ3iMJ6w== M;Og+mWjvI5xG9d4lQ3iMJ6w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4qxh26_wya3FS1YEUZU9TodzXBk>
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 06:25:00 -0000

Ole,

> 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. ;-)

Has this or is this being deployed?

Seems like some solution would be needed to avoid running out of prefixes.


> - 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

Yes, I can see how one can use loss of the link/association to trigger 
this in some cases. But even in those cases/topologies if the host 
looses the link and reconnects it isn't necessarily going to redo the RS 
hence you can't tell whether it is still there or not.

> 
> 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.

Yeah that soft state approach has been shown to be useful in other 
protocols. In this particular case it would require the hosts to send 
some form of "refresh" packet, which could be a unicast RS or anything 
else we'd like.


    Erik