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

Joel Jaeggli <joelja@bogus.com> Wed, 09 November 2022 06:10 UTC

Return-Path: <joelja@bogus.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 30762C14CE20 for <v6ops@ietfa.amsl.com>; Tue, 8 Nov 2022 22:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=unavailable autolearn_force=no
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 0C_4_FVfQ6zl for <v6ops@ietfa.amsl.com>; Tue, 8 Nov 2022 22:10:25 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 D965BC159485 for <v6ops@ietf.org>; Tue, 8 Nov 2022 22:10:25 -0800 (PST)
Received: from [IPV6:2601:1c1:8380:9e1:cc72:83da:4492:c463] ([IPv6:2601:1c1:8380:9e1:cc72:83da:4492:c463]) (authenticated bits=0) by nagasaki.bogus.com (8.16.1/8.16.1) with ESMTPSA id 2A96ALRm081736; Wed, 9 Nov 2022 06:10:22 GMT (envelope-from joelja@bogus.com)
Message-ID: <de75bee9-9075-e3a6-c633-3d74c609236d@bogus.com>
Date: Tue, 08 Nov 2022 22:10:15 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
To: Jen Linkova <furry13@gmail.com>
Cc: Ole Troan <otroan=40employees.org@dmarc.ietf.org>, V6 Ops List <v6ops@ietf.org>
References: <CAFU7BAQV5eeO3EKWXyTYDnsnAUhLCi-j-b7tkAJ5K79+-qSN9g@mail.gmail.com> <9AC65596-7EFC-4543-B303-7B39329F1076@employees.org> <c13e5d81-6dcf-133c-e82f-da5657c8247e@bogus.com> <CAFU7BAREv7buOZySUTKS=01oPyQx5ZBMuwHfLURuwTSvqDaSnA@mail.gmail.com>
Content-Language: en-US
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <CAFU7BAREv7buOZySUTKS=01oPyQx5ZBMuwHfLURuwTSvqDaSnA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/gNNKbCDUgVPn5magbfZhsTT7iGs>
Subject: Re: [v6ops] Fwd: 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 06:10:30 -0000

On 11/8/22 04:39, Jen Linkova wrote:
>> We've been around that particular point a few times over the years. It
>> seems relatively straight forward to implement prefix per host without
>> much in the way of coordination with the host, for example if you also
>> have layer-2 isolation per host you can delegate a prefix to it and
>> install the whole prefix with the host as the l2 nexthop. this gives you
>> one route per host  which is manageable and allows for arbitrary usage
>> within the the delegated prefix /64 /60 /56 whatever. you can go still
>> further on a switch and construct an exact match table at said prefix
>> size and now /64 routes (for example) are host routes.
> Yes, that's a very good long-terms solution which requires changing
> the way operators design the networks.

it's relatively modest variation for a lot of service provider edges, 
where private vlans, layer 3 ports or tunnels over which service is 
provisioned are present.  for large layer 2 networks or cases where 
clients can  gratuitously  bridge it's less ideal.

broadly a hosts nic can be unicasted to for whatever IPs it happens to 
be using so devolves to number of macs in use on a port rather than 
number of IPs

> Actually the purpose of this draft is to slightly increase the
> probability of a random device to work correctly on a random
> conference/enterprise WiFi.
controller based wifi networks which generally presume client isolation 
as part of their function seem well suited to such impelmentation.
> I do not need this draft to fix *my* network problem - I'll make sure
> all devices in my network have reasonable limits configured from now
> on.
> My concern is that a random network engineer deploys a guest WiFi
> network (just a vlan, with peer2peer isolation probably) and random
> people join that network with their devices - that setup has
> reasonable default settings.
>
>> I have implemented something similar with host coordination where source
>> address selection on a host is done  from a prefix (/48) bound to the
>> the loopback on the host with the practical consequence that hosts use
>> low numbers of millions of ipv6 addresses per day with no more overhead
>> from the vantage point of the switch than using 1
> That's very interesting, thanks Joel. I might come back to you with
> more questions.
> I assume you are talking about controlled environments, right?

the coordinated case is a datacenter. in that case the goal is to 
minimize the resource consumption while having some modicom of control 
over both ends. in the case the end system is aware of and takes 
advantage of the large pool of source IPs.

>>>> On 8 Nov 2022, at 02:25, Jen Linkova <furry13@gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> As I've come across some rather nasty failure scenarios, affecting
>>>> both IPv6-only and dual-stack deployments, I think it might be useful
>>>> to re-emphasize RFC7934 and provide some recommendations to vendors.
>>>>
>>>> This is a rather raw -00, the text is very brief and unpolished, it
>>>> will be definitely expanded and improved, should the group agree that
>>>> this is a problem worth solving.
>>>>
>>>> Feedback/comments are appreciated indeed!
>>>> Thanks!
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: <internet-drafts@ietf.org>
>>>> Date: Tue, Nov 8, 2022 at 12:15 PM
>>>> Subject: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt
>>>> To: Jen Linkova <furry13@gmail.com>
>>>>
>>>>
>>>>
>>>> A new version of I-D, draft-linkova-v6ops-ipmaclimi-00.txt
>>>> has been successfully submitted by Jen Linkova and posted to the
>>>> IETF repository.
>>>>
>>>> Name:           draft-linkova-v6ops-ipmaclimi
>>>> Revision:       00
>>>> Title:          Minimizing Damage of Limiting Number of IPv6 Addresses per Host
>>>> Document date:  2022-11-07
>>>> Group:          Individual Submission
>>>> Pages:          5
>>>> URL:
>>>> https://www.ietf.org/archive/id/draft-linkova-v6ops-ipmaclimi-00.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-linkova-v6ops-ipmaclimi/
>>>> Html:
>>>> https://www.ietf.org/archive/id/draft-linkova-v6ops-ipmaclimi-00.html
>>>> Htmlized:
>>>> https://datatracker.ietf.org/doc/html/draft-linkova-v6ops-ipmaclimi
>>>>
>>>>
>>>> Abstract:
>>>>     This document provides recommendations to network infrastructure
>>>>     vendors on how to deal with multiple IPv6 addresses per host.
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> SY, Jen Linkova aka Furry
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>
>