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

> 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.
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.
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?

> >> 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
> >

-- 
SY, Jen Linkova aka Furry