Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

Hi,
I like this proposal for the SLAAC deprecation in the limited (Enterprise) domain. It would greatly help for IPv6 Enterprise adoption. DHCP's absence is the biggest issue for this market segment.
The solution needs a name for a short reference. Something like "DHCP prefix per host".

1.	What is the point to keep SLAAC if DHCP infrastructure is mandatory? I do not understand what SLAAC is left in this solution. DAD, PIO - all looks gone. In fact, this proposal is the SLAAC deprecation (despite many claims that it is not). It is visible in section 8 when discussing "SLAAC" against "prefix per host" methods.
2.	Choosing the IID is a fully "local matter" for this solution. The host could easily choose from /96. It is discussable how many bits are needed for good IID randomization (is 32 bits enough?).
It is a good opportunity to move the prefix to something much longer. It is not a problem for DHCP.
3.	The proposal would not resolve MHMP (on PA addresses): the host is still not capable of properly choosing which prefix to use. The root cause is that the next hop is chosen before the source address (by getaddrinfo()). It could be discussed separately.
4.	It was possible to improve a little routing (aggregation) by asking the DHCP server to delegate prefixes closest (by mask) to the router interface on the link. In the case of longer prefixes (/96) - it is possible to delegate from the single /64.
it is probably needed to have two /64 for the router on the link to support the transition period of the new solution and the SLAAC at the same time.
5.	The current privacy RFC is broken by this solution but it is not a problem - it may be updated later.

Indeed, it could be v6ops RFC because it is "local matters" for hosts and routers.
It does not break SLAAC. It just deprecates it.
Some sort of SLAAC replacement by DHCP.
Exactly what many Enterprise people were demanding for a long time.

Eduard
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova
Sent: Thursday, December 15, 2022 7:00 AM
To: V6 Ops List <v6ops@ietf.org>
Cc: draft-collink-v6ops-ent64pd@ietf.org; xiaom@google.com
Subject: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

Hello,

We've just submitted -01 version of draft-collink-v6ops-ent64pd, which proposes using DHCPv6-PD to delete /64 per host (the draft was very briefly presented at the last IETF).

Comments and suggestions are welcome!

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Thu, Dec 15, 2022 at 2:39 PM
Subject: New Version Notification for draft-collink-v6ops-ent64pd-01.txt
To: Jen Linkova <furry13@gmail.com>, Lorenzo Colitti <lorenzo@google.com>, Xiao Ma <xiaom@google.com>

A new version of I-D, draft-collink-v6ops-ent64pd-01.txt
has been successfully submitted by Jen Linkova and posted to the IETF repository.

Name:           draft-collink-v6ops-ent64pd
Revision:       01
Title:          Using DHCP-PD to Allocate /64 per Host in Broadcast Networks
Document date:  2022-12-14
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/archive/id/draft-collink-v6ops-ent64pd-01.txt
Status:         https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/
Html:
https://www.ietf.org/archive/id/draft-collink-v6ops-ent64pd-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-collink-v6ops-ent64pd
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-collink-v6ops-ent64pd-01

Abstract:
   This document discusses the IPv6 deployment scenario when individual
   hosts connected to broadcast networks (like WiFi hotspots or
   enterprise networks) are allocated /64 subnets via DHCP-PD.

The IETF Secretariat

--
SY, Jen Linkova aka Furry

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops