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

How is it possible to argue against DHCP?

Of course, it is possible to reinvent the wheel,

And develop special patch for the particular problem (better the limit to be dynamic).

DHCP has 144 options: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml.

Well, many represent some corner cases,

But a few dozen for sure would be needed in the Enterprise environment.

Patching all of them at SLAAC would take decades.

Just look at the list for those that are blocked:
DHCP for Prefix Delegation

DHCP Unique Identifier for log

(Server) Preference Option

Authentication Option

User Class Option

Vendor Class Option

Vendor-specific Information Option

Identity Association for Prefix Delegation Option

INTERFACE_ID

IP_SERVER

NIS_SERVERS

NIS_DOMAIN_NAME

REMOTE_ID

SUBSCRIBER_ID

CLIENT_FQDN

NEW_POSIX_TIMEZONE

CAPWAP_AC_V6

RELAY_ID

NTP_SERVER

V6_ACCESS_DOMAIN

BOOTFILE_URL

BOOTFILE_PARAM

CLIENT_ARCH_TYPE

GEOLOCATION

AFTR_NAME

RADIUS

V6_PCP_SERVER

Access-Network-Identifier Option

V6_PREFIX64

DNS_HOST_NAME

DNS_ZONE_NAME

Failover Protocol

Secure Zero Touch Provisioning

Link-Layer Address Assignment Mechanism for DHCPv6

MAC assignment

DDoS Open Threat Signaling (DOTS) Agent Discovery

Discovery of Network-designated Resolvers (DNR)

It is a good assurance for no-go in the Enterprise environment.

Eduard

-----Original Message-----
From: Vasilenko Eduard
Sent: Tuesday, November 8, 2022 9:55 PM
To: 'Ole Troan' <otroan=40employees.org@dmarc.ietf.org>; Jen Linkova <furry13@gmail.com>
Cc: V6 Ops List <v6ops@ietf.org>
Subject: RE: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt

+1

In the DHCP environment - it would not happen automatically, the DHCP would not permit stretching the limit.

Ed/

-----Original Message-----

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ole Troan

Sent: Tuesday, November 8, 2022 4:44 PM

To: Jen Linkova <furry13@gmail.com<mailto:furry13@gmail.com>>

Cc: V6 Ops List <v6ops@ietf.org<mailto:v6ops@ietf.org>>

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

> On 8 Nov 2022, at 14:15, Jen Linkova <furry13@gmail.com<mailto:furry13@gmail.com>> wrote:

>

> On Tue, Nov 8, 2022 at 11:46 PM Ole Troan <otroan@employees.org<mailto:otroan@employees.org>> wrote:

>>> It is not about address assignment mechanisms. You'd hit the same

>>> issue if you configure addresses statically.

>>

>>

>> You are pointing out fundamental issues with SLAAC.

>

> Wait. Before we burn any more energy, let me repeat what you've just

> said to make sure we are on the same page.

>

> You are saying that an issue which manifests itself even if I

> configure addresses manually, is a fundamental problem with SLAAC?

> Would you be able to elaborate on that statement a bit (if I

> understood correctly, indeed - my apologies if I didn't).

The fundamental issue with SLAAC, is the expectation in the protocol design that a host can configure as many addresses as it likes, with no limits applied by the network.

Manual configuration is not relevant here. In many networks manual configuration is prohibited by the network. Configuring more addresses than permitted is then a misconfiguration. Don’t do that.

Creating a decree for the minimum number of addresses per host is increasing the cost for everyone. Doesn’t solve the exhaustion and control issues.

An IPV6 TCAM entry is 4x as large as an IPv4 one. With 20 addresses per host, wouldn’t IPv6 consume 80x-ish the resources compared to IPv4?

O.

>> There is no negotiation with the network nor any signal available (apart from DAD) to tell the host that it has exhausted the number of addresses available.

>> This is better in DHCP.

>>

>> Also host implementations do not have a way to relinquish addresses, so resource management becomes unnecessarily complicated on the network side.

>

> It's not a ND-specific issue, and I'd expect LRU (or any other

> reasonable algorithm for cache entries replacement would help.

>> You can keep increasing limits on the state tables, but since this is

>> easily attackable (there are also software bugs where stacks

>> unwittingly gone wild in assigning addresses to themselves)

>

> I have a lot of BGP sessions on which max-prefix-limit is configured.

> In the past 15 years I had to increase those limits many times. I do

> not think the argument of "let's keep the same limit we hardcoded 20

> years ago, because keep increasing it impractical, and sometime people

> do leak full view to peers" would fly.

>

>> it is like peeing in your pants to keep warm.

>

> I'd refrain from comments on the applicability of this analogy ;)

>

> --

> SY, Jen Linkova aka Furry

_______________________________________________

v6ops mailing list

v6ops@ietf.org<mailto:v6ops@ietf.org>

https://www.ietf.org/mailman/listinfo/v6ops