IETF Logo Mail Archive

Re: [v6ops] New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt

Ivan Pepelnjak <ipepelnjak@gmail.com> Wed, 09 November 2022 16:32 UTC

Return-Path: <ipepelnjak@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0ADC14CE27 for <v6ops@ietfa.amsl.com>; Wed, 9 Nov 2022 08:32:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4q4O5LhU26v for <v6ops@ietfa.amsl.com>; Wed, 9 Nov 2022 08:32:52 -0800 (PST)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CF7C14CE2B for <v6ops@ietf.org>; Wed, 9 Nov 2022 08:32:52 -0800 (PST)
Received: by mail-wr1-x429.google.com with SMTP id z14so26592445wrn.7 for <v6ops@ietf.org>; Wed, 09 Nov 2022 08:32:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=K1YBiwK+2OVQY7U2ygo64rbjOsapMLeeGI4WSEml3gc=; b=EZAuJ02K8EgYM4OJDe+tM4pKzLowAmhL/uCQELad2juxM5AM0IeNeUUZnBsTueMc/I T1cX5BAa0iRLsz2d/UmKZWUfPKX5NlVnzuzckqvTgObUPZwbB11924ylrzdM3ZZRqF2Z IIgAiCth1qdxG7hj17vBIspw+jcNZCrkmu77xJSdZpjRwNKBxdwtcngtOv2+ELcXscw2 h2NtUkXZnrYG47O/W+BFcUi1YSzoylYo+gd0XElvle5c/at88uwBCBj9Qffv4XH62jYk s+Yfy3jJ90jd0Rt6RQvv2Y9TnXNg2pnIsKNXsbZ1xCgQYO8f7QjFTzAlzocL0poUQ2BP X+aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=K1YBiwK+2OVQY7U2ygo64rbjOsapMLeeGI4WSEml3gc=; b=vASwnDdqdFiRK/jqvLaHK8g7q/QuKNlCbqPfs0K9TV9e97KdraO9N4xqGXwFEpxkGQ dxjt94kqv7JbV6eic5yrYQ0/9ucGg4Z4KSkUc1Osd3f/T1M7o2CsPHIbyJ7R8D8KRP7v jjwV9b45qLJ8TUKknRJaAo0smEc6gx2KuqRJIWNgi9To2t1wejwQ0VnSqZZK2F+sB2qg jsku4zbKk8J8DpIvxxYA3dR31fYc17nJWCY3XsNY44aoMdKkZqisVwQDPY5T9KSnyIFx TYTeBhcqy+KkyB70mGJ3JDFpwfB9HuuiXSLV/EAPQFaB4ZRgn9oSm2Z9Xq1U7x0xfkXX qugg==
X-Gm-Message-State: ACrzQf09YlZtgExHbdhTSx5jbB/+efV5rleN54EBdAXfym6wG9h4fOAI kCadvBmMYwo1rLHpvCJejMznalm1iSo=
X-Google-Smtp-Source: AMsMyM5MyUf7OCdxBkBc4JvhLAdV9DFvj1V1oDzcFmh5/Fl4FRSGwXddFotwReSlhvaqsn9OQHDlRQ==
X-Received: by 2002:adf:fd0f:0:b0:236:5ede:9f8e with SMTP id e15-20020adffd0f000000b002365ede9f8emr921643wrr.372.1668011569990; Wed, 09 Nov 2022 08:32:49 -0800 (PST)
Received: from smtpclient.apple (BSN-142-170-80.static.siol.net. [89.142.170.80]) by smtp.gmail.com with ESMTPSA id s7-20020adfeb07000000b0022a3a887ceasm13304563wrn.49.2022.11.09.08.32.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2022 08:32:49 -0800 (PST)
From: Ivan Pepelnjak <ipepelnjak@gmail.com>
X-Google-Original-From: Ivan Pepelnjak <IPepelnjak@gmail.com>
Message-Id: <07B7D59D-EA9C-4B5F-8388-276C5ECA50D5@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_25ED3DE3-AF3A-4D83-BEE6-FAA7E9E28599"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Wed, 09 Nov 2022 17:32:47 +0100
In-Reply-To: <ed4d98ac-4164-b451-5d85-197f0f8d80b7@foobar.org>
Cc: Mark Smith <markzzzsmith@gmail.com>, V6 Ops List <v6ops@ietf.org>
To: Nick Hilliard <nick@foobar.org>
References: <166787013771.45604.8636622079744458317@ietfa.amsl.com> <CAFU7BAQV5eeO3EKWXyTYDnsnAUhLCi-j-b7tkAJ5K79+-qSN9g@mail.gmail.com> <90963634-b469-a959-321c-8431e21dae85@foobar.org> <CAO42Z2yoveziP3wz0oDCQjPrs=zkLLfaJ2z0tePocPQjZFZSAQ@mail.gmail.com> <a4887c00-fec1-39f7-1362-2ac08e545072@foobar.org> <CAO42Z2z8kLCoU+=G1mOHrKnaXufCat5WZ-F7KqbUdJUhZ2iY-A@mail.gmail.com> <ed4d98ac-4164-b451-5d85-197f0f8d80b7@foobar.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/aLhQh5-Vxoli1US9vY01bs3FnJ0>
Subject: Re: [v6ops] New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2022 16:32:55 -0000

Don’t try to reverse-engineer today’s “client versus network” discussions into how SLAAC came to be. I’ve been around at the time when SIP address suddenly got twice as many bits with the idea that the MAC address would be in the lower half. Also, there was no DHCP at that time, and it was embarrassing that something as stupid as Novell IPX had autoconfiguration but IP didn’t.

For more details, read https://www.rfc-editor.org/rfc/rfc1752.html#section-9 <https://www.rfc-editor.org/rfc/rfc1752.html#section-9>

No surprise, SLAAC got abused like every other network technology (the distributed data store protocol called BGP immediately comes to mind)

> On 9 Nov 2022, at 13:47, Nick Hilliard <nick@foobar.org> wrote:
> 
> Mark Smith wrote on 08/11/2022 22:16:
>> These problems fundamentally exist because hosts are in a position to create state in network elements without getting authorisation and therefore exhaust that state capacity
> 
> The IETF designed slaac with a specific philosophy in mind, namely that the network client should not be especially constrained by the policies of the network operator. Part of this approach included giving slaac a default free-for-all in terms of number resource acquisition inside any particular prefix. So this didn't happen by accident - it was a fundamental design choice.
> 
>> This is not a new problem, IPv4 ARP caches have always been vulnerable to state capacity exhaustion.
> 
> You're correct that it's not a new problem: for mechanisms like DHCP/ipv4, static/ipv4 and static/ipv6, the client needs to set out to go out of its way to claim network resources.  With DHCPv6, the problem can be managed by setting per-client limits.  What's different with SLAAC is that unconstrained resource acquisition is enabled by default and there's no option to disable or constrain the behaviour.
> 
> Nick
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email