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

joel jaeggli <joelja@bogus.com> Fri, 10 November 2017 05:57 UTC

Return-Path: <joelja@bogus.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 4AF6712EB04; Thu, 9 Nov 2017 21:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 OQVbwxuRB8ET; Thu, 9 Nov 2017 21:57:39 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B7A12EB02; Thu, 9 Nov 2017 21:57:38 -0800 (PST)
Received: from mb.local ([111.223.75.82]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vAA5vZfl012463 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 10 Nov 2017 05:57:36 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [111.223.75.82] claimed to be mb.local
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont <fgont@si6networks.com>, Erik Kline <ek@google.com>
Cc: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" <v6ops-ads@ietf.org>, draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <CAAedzxpLL26kDi1yzB=rDQjuNOpb64wtCBMcP+VYf=dc54rF7w@mail.gmail.com> <65664ca5-b8fe-0ca0-82fc-99e120426aea@si6networks.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <f3fb649f-9f41-bfc1-04fc-b36372cb677b@bogus.com>
Date: Fri, 10 Nov 2017 13:57:28 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <65664ca5-b8fe-0ca0-82fc-99e120426aea@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/xEBRuEL9zM0zMmw-TrDBmfOXK0U>
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: Fri, 10 Nov 2017 05:57:40 -0000

On 11/9/17 16:05, Fernando Gont wrote:
> On 11/09/2017 12:02 AM, Erik Kline wrote:
>> I don't think we should be recommending unique RAs per device where
>> the devices are all on a shared link.
> 
> Agreed.
> 
> And if we were to do it, we should be recommending this in a 6man
> document, not v6ops.
> 
> 
> 
>> My understanding was that in the original motivating wifi deployment
>> every node is effectively isolated in its own (pseudo)VLAN, and
>> node-to-node traffic must be routed through the infrastructure (to the
>> extent such a thing can actually be enforced in a medium like wifi).
> 
> Describing the virtues of one prefix per node, or how isolating nodes
> (no "on link prefix") or the like are all fine for an informational
> document, or even as a BCP (if that's how the wg feels).

there is an available recourse to an onlink prefix in form of the
link-local address for a deligated prefix.

   Or, optionally in some cases, a
   solicited RA response could be sent unicast to the link-local address
   of the subscriber as detailed in RFC4861

https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13#section-4


> Specifying hacks to SLAAC which require modification to the SLAAC router
> code (you certainly need to hack e.g. radvd quite a lot to implement
> this) or add additional requirements to SLAAC (like the requirement of a
> data structure that contains mappings of Prefix_leased -> MAC_address)
> is std track work that should be done in 6man, and with a document
> flagged as "std track", not bcp.
>