Re: RFC4941bis: consequences of many addresses for the network

Fernando Gont <fgont@si6networks.com> Fri, 24 January 2020 18:24 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 1AE4E120875 for <ipv6@ietfa.amsl.com>; Fri, 24 Jan 2020 10:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 n3kHYXGi9tnl for <ipv6@ietfa.amsl.com>; Fri, 24 Jan 2020 10:24:24 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D519120B20 for <ipv6@ietf.org>; Fri, 24 Jan 2020 10:24:24 -0800 (PST)
Received: from [192.168.100.103] (unknown [186.183.3.105]) (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 D8E65867B1; Fri, 24 Jan 2020 19:24:13 +0100 (CET)
Subject: Re: RFC4941bis: consequences of many addresses for the network
To: Michael Richardson <mcr@sandelman.ca>
Cc: 6man WG <ipv6@ietf.org>
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <MN2PR11MB3565330989D411525D30B90DD80F0@MN2PR11MB3565.namprd11.prod.outlook.com> <80207E17-AE8E-4D19-B516-D2E6AB70721E@employees.org> <8D5610EA-49D3-483E-BB7A-67D67BC89346@jisc.ac.uk> <DE7B0688-230F-4A5C-8E24-9EAED9FD9FEB@puck.nether.net> <CAO42Z2zXwVnzemRqyqy78czpHjZm0nhkCJgVrx=-fmt+C6MnSA@mail.gmail.com> <1962.1579823388@localhost> <d56939d6-d577-ced3-e1e7-a4713bc95cd9@si6networks.com> <30049.1579886239@localhost>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <430fb77a-1c9b-a5d2-1c45-4e6af2428c8b@si6networks.com>
Date: Fri, 24 Jan 2020 15:22:58 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <30049.1579886239@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hREG2YBizlkPoQFZIzBAUDFIXNE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Jan 2020 18:24:31 -0000

On 24/1/20 14:17, Michael Richardson wrote:
> 
> Fernando Gont <fgont@si6networks.com> wrote:
>      > PLease let me reiterate: the problem being discussed in this thread is a
>      > shortcoming of slaac.
> 
> I think that the problem is bigger than SLAAC.  That's just one way to
> configure addresses, and as you said, the problem is about communicating policy.

Well... right now, we essentially jave three mechanisms for configuring 
addresses:

1) SLAAC
2) DHCPv6
3) Manual configuration

1) could convey policy, but doesn't. And when I proposed it almost ten 
years ago, the group rejected it -- might try again, though.

2) Doesn't need to convey policy, for the most part, because the dhcpv6 
server itself can enforce the policy

3) involves no communication with anyone -- i.e., you do your own thing, 
so there's no place for communicating policy.


If you have a network that might break if, e.g., nodes were to configure 
IPv6 addresses, then you should be doing DHCPv6, and make sure you don't 
lease more addresses than the one your devices can handle. -- this would 
mean universal support of DHCPv6: i.e., update node requirements, and 
make dhcpv6 mandatory.

For slaac, you could certainly flag whether you want hosts to configure 
temporary addresses or not. BUt for other stuff, it's tricky. At the end 
of the day, what matters is the number of addresses in use. So it's not 
just how many addresses a node configures, but also how many nodes 
attack to your network. Restricting 10 addresses per gost when only 5 
hosts attach to your network would seem overly constricting.

Although, if you have multiple routers on the network, and they 
advertise different prefixes, then nodes might direct packets to the 
wrong router, and then you'd be affected by addresses configured for 
prefixes you don't even advertise.

SLAAC is, for better or worse, configuration anarchy. Not sure how much 
sense it makes to stick to anarchy and expect order....

(full disclosure: i have no personal preference for slaac or dhcpv6. I 
personally think each of them have a place. The part I strongly disagree 
with is the religious war where folks seem to believe that you must 
support one xor the other, and that each of them apply well to all 
scenarios).



>      > It's certainly fine to add a note along the lines of "hey! don't regenerate
>      > addresses too frequently (i.e., beware when overriding default falues(, or
>      > else you might end up screwing the network".
> 
>      > But other than that, 4941bis is not about addressing shortcomings of slaac.
> 
> I think that 4941bis should say something about the network cost.
> Section 3.5 has a paragraph about the client costs of having a large number
> of addresses, and maybe that's a place to talk about what happens if there
> are too many.
> 
> I think that we need some way for a host to recognize that it's used too many
> temporary addresses.  I wish that 6man-grand was able to add some kind of ACK
> from the routers, but that won't scale.  So, we need a heuristic.
> I would be happy if the document just said that this is a place for future work.

If you can craft some text for the "future work" part, that'd be 
appreciated.




> ----
> 
> I also think that 3.6 should suggest that the enable/disable should be
> settable on a per-attachment ("ESSID" aka "Provisioning Domain") basis.  The
> text about doing this per-prefix would seem to mostly address this
> requirement, but I'd prefer to write this differently.  Maybe it's enough to
> start a new a paragraph at "Another site..."

How about:
"An implementation SHOULD provide a way for a trusted administrator to 
enable or disable the use of temporary addresses on a per-ESSID basis. 
This would allow an administrator to enable or disable the use of 
temporary addresses for specific networks."

Thoughts?


> I don't know how a "site" will communicate it's need to the OS, except via a
> trusted administrator.  Maybe I missed somethinig?

Same as for disabling temporary addresses. (trusted admin)


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