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

Fernando Gont <fgont@si6networks.com> Fri, 10 November 2017 20:21 UTC

Return-Path: <fgont@si6networks.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 524E4128CD5; Fri, 10 Nov 2017 12:21:48 -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 HEujzgAS5onT; Fri, 10 Nov 2017 12:21:47 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6167129476; Fri, 10 Nov 2017 12:21:46 -0800 (PST)
Received: from [10.234.32.137] (unknown [87.200.50.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5194082995; Fri, 10 Nov 2017 21:21:43 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fred Baker <fredbaker.ietf@gmail.com>, Lorenzo Colitti <lorenzo@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> <CAKD1Yr0_a2Qm8U4oK+BQU57DeDUD9i-o_+G+YhnH4pVXRxmxxQ@mail.gmail.com> <BBB987EF-D91C-4FD1-9084-21382F24E7BF@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com>
Date: Fri, 10 Nov 2017 17:23:29 -0300
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: <BBB987EF-D91C-4FD1-9084-21382F24E7BF@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/pyHxr52NdsooZJ22Ks7JqvZCykU>
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 20:21:48 -0000

Hi, Fred,

On 11/10/2017 01:12 AM, Fred Baker wrote:
> 
> 
>> On Nov 9, 2017, at 8:28 AM, Lorenzo Colitti <lorenzo@google.com>; wrote:
>>
>> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont <fgont@si6networks.com>; wrote:
>> 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.
>>
>> I don't see how this is a protocol change. Sending RAs unicast is already allowed by RFC 4861, so this is just an operational practice.
> 
> I understand the concern to be sending to a multicast address at the network layer and a unicast address at the link layer. If 4861 allows the RA to be sent unicast, it is probably unicast at both layers. I suspect that if we change to doing what 4861 describes we'll be fine.

At which point you realize that know you have to no implement the
graituous  all-nodes RAs, and it becomes evident that you are changing
the spec.

THe main issue is not this but, as the subject implies, this document
making SLAAC stateful.

But, anyway, it should be easy to have all of us converge on something:
the whole discussion boils down to whether this is or is not a protocol
spec.

So, my request would be. For folks arguing that this document is not a
protocol spec, could you please provide a definition of what a protocol
is, and subsequently explain why/how such definition does not encompass
this document?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492