IPv6 fc00::/7 — Unique local addresses

Mailman List Mirror (Read Only)
121

> >
> > How so? We still have RA (with a high priority) that's the only way
> > DHCPv6 works. I guess there is a lot of misunderstanding about how
> > DHCPv6 works, even among the experts...
>
> Actually, the last I checked, there are implementation of DHCPv6 without RA.

I'll go out on a limb here and say that RA is not needed for DHCPv6.

RAs are still needed to convey the M/O bit values, so that end-nodes
know they need to use DHCPv6 if necessary. As there are two address
configuration methods, there is always going to be a need to express a
policy to end-nodes as to which one they need to use.

A DHCPv6 client multicasts all its messages to the well-known
all-relays-and-servers address. A client needs only its link-local
address to do this. The relay (or server if it happens to be on the same
link) can thus talk to the client in the complete absence of RA.

There isn't a method to specify a default gateway in DHCPv6. Some
people want it, however it seems a bit pointless to me if you're going
to have RAs announcing M/O bits anyway - you may as well use those RAs
to announce a default router too.

Regards,
Mark.

122

How so? We still have RA (with a high priority) that's the only way
DHCPv6 works. I guess there is a lot of misunderstanding about how
DHCPv6 works, even among the experts...

Actually, the last I checked, there are implementation of DHCPv6 without RA.

I'll go out on a limb here and say that RA is not needed for DHCPv6.

RAs are still needed to convey the M/O bit values, so that end-nodes
know they need to use DHCPv6 if necessary. As there are two address
configuration methods, there is always going to be a need to express a
policy to end-nodes as to which one they need to use.

You can actually force a client to assume the M bit if you cause it to launch
a DHCPv6 client through other means. You don't have to have RA for that.
Policy can be expressed by RA, or, it can be expressed by other means.

A DHCPv6 client multicasts all its messages to the well-known
all-relays-and-servers address. A client needs only its link-local
address to do this. The relay (or server if it happens to be on the same
link) can thus talk to the client in the complete absence of RA.

There isn't a method to specify a default gateway in DHCPv6. Some
people want it, however it seems a bit pointless to me if you're going
to have RAs announcing M/O bits anyway - you may as well use those RAs
to announce a default router too.

Actually, it's not pointless at all. The RA system assumes that all routers
capable of announcing RAs are default routers and that virtually all routers
are created equal (yes, you have high/medium/low, but, really, since you
have to use high for everything in any reasonable deployment...)

There are real environments where it's desirable to have a way to tell
different clients on a network to use different default gateways or
default gateway sets.

Owen

123

The design of IPv6 is that DHCPv6 and RA work together. This is why
there is no method to express the default gateway using DHCPv6, that
task is handled by the RA. I suppose you could run DHCPv6 on a subnet
to give hosts addresses but never give them a default gateway, but
that would be a little useless no?

Please stop confusing people about DHCPv6. There is already enough
misinformation out there.

It's starting to feel like Fox News here, next there will be another
post citing yours saying "experts on NANOG have said that DHCPv6
doesn't require RA" and make users spend hours looking for how to set
the gateway address.

124

A filter away from leaking to -one- of the millions of entities on the
internet. Two filters away from leaking to two.

Regards,
Bill Herrin

125

In a message written on Fri, Oct 22, 2010 at 06:25:18PM +1030, Mark Smith wrote:

There isn't a method to specify a default gateway in DHCPv6. Some
people want it, however it seems a bit pointless to me if you're going
to have RAs announcing M/O bits anyway - you may as well use those RAs
to announce a default router too.

There are some folks (like me) who advocate a DHCPv6 that can convey
a default gateway AND the ability to turn off RA's entirely. That
is make it work like IPv4.

There are pros, and cons; but I can think of a number of deployment
scenarios where it would be a vast improvement and beleive strongly
operators should have the choice.

Unfortunately the folks in the IETF don't even want to listen, to the
point a working group chair when I tried to explain why I wanted such a
feater told the rest of the group "He's an operator and thus doesn't
understand how any of this works, ignore him." That's when I gave up
on the IETF, and started working on my vendor for the solution.

126

Works great when you don't need routing.

DHCPv6 doesn't have an option for a default gateway/router

There. No confusion. RA isn't the only way to load a route. It's just the most supported.

Jack

127

It's popped around multiple times. The drafts won't stop until it's implemented. The lack of it in DHCPv6, despite obvious desire for it, seems to indicate a bias on the part of the IETF.

Here's a current draft http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05

Jack

128

This underestimates the transitive property of leakage.

Owen

129

It's amazing how much of a problem you think leaking of prefixes is...

I don't know about you, but I'm pretty strict about what prefixes I
allow to be advertised up to me from people we service.

I'm not sure having a random private prefix will make much of a
difference, since it sounds like fat-fingering a GUA and hijacking a
real prefix is just as (or even more) likely.

I think the original point was that if you do decide to use ULA, then
stay in FD00::/8 and not FC00::/7, there is no way to force people to
follow the RFC for something thats non-routed unless we involve
vendors.

If it sounds like a good idea to include the random 40-bit segment and
you can tolerate having non-routed addresses be a little more
difficult to remember, then go for it. If you don't follow the RFC
and it bites you because of a merger in the future, then it's your own
fault and you haven't affected anyone.

In the vast majority of environments, even if this space did leak out
into the global table and wasn't filtered at all, you would probably
still maintain normal operation because your non-routed networks would
be a shorter path than anything advertised back down to you.

Do we really need 80 messages talking about the dangers of leaking?
Perhaps you should see your doctor if its that big of a problem. I
think there are some drugs to fix that problem these days...

The obvious assumption is that anyone who is providing IPv6 transit is
already protecting themselves appropriately, just as they already do
in the IP world.

130

Unfortunately the folks in the IETF don't even want to listen, to the
point a working group chair when I tried to explain why I wanted such a
feater told the rest of the group "He's an operator and thus doesn't
understand how any of this works, ignore him." That's when I gave up
on the IETF, and started working on my vendor for the solution.

It's popped around multiple times. The drafts won't stop until it's
implemented. The lack of it in DHCPv6, despite obvious desire for it, seems
to indicate a bias on the part of the IETF.

The interesting thing is that while the IETF may have a certain bias, the
hardware manufacturers have a different bias; they do what needs to be
done to sell hardware. And while we may be 'just operators', if we tell
vendors we won't buy their hardware unless they support draft-X-Y-Z,
you can believe they'll listen to that a lot more closely than they will
the IETF.

The IETF has teeth only so long as those with money to spend on
vendors support their decisions. When a vendor is forced to choose
between complying with the IETF, or getting a $5M purchase order
from a customer, they're going to look long and hard at what the
customer is requesting. We've gotten knobs added to software
that go explicitly against standards that way; they're off by default,
they're hidden, and they have ugly names like "enable
broken-ass-feature-for-customer-X"
but the vendors *do* put them in, because without them, they don't
get paid.

Matt

131

>
>>>>
>>>> How so? We still have RA (with a high priority) that's the only way
>>>> DHCPv6 works. I guess there is a lot of misunderstanding about how
>>>> DHCPv6 works, even among the experts...
>>>
>>> Actually, the last I checked, there are implementation of DHCPv6 without RA.
>>
>> I'll go out on a limb here and say that RA is not needed for DHCPv6.
>>
>
> RAs are still needed to convey the M/O bit values, so that end-nodes
> know they need to use DHCPv6 if necessary. As there are two address
> configuration methods, there is always going to be a need to express a
> policy to end-nodes as to which one they need to use.
>
You can actually force a client to assume the M bit if you cause it to launch
a DHCPv6 client through other means. You don't have to have RA for that.
Policy can be expressed by RA, or, it can be expressed by other means.

We used to hand wind cars to start them. We don't have to anymore.

An RA is single, periodic, in the order of 100s of seconds, multicast
packet. If you're arguing against the cost of that, then I think you're
being a bit too precious with your packets.

Any argument for manual configuration is an argument for increasing
complexity and opportunity for error.

>> A DHCPv6 client multicasts all its messages to the well-known
>> all-relays-and-servers address. A client needs only its link-local
>> address to do this. The relay (or server if it happens to be on the same
>> link) can thus talk to the client in the complete absence of RA.
>>
>
> There isn't a method to specify a default gateway in DHCPv6. Some
> people want it, however it seems a bit pointless to me if you're going
> to have RAs announcing M/O bits anyway - you may as well use those RAs
> to announce a default router too.
>
Actually, it's not pointless at all. The RA system assumes that all routers
capable of announcing RAs are default routers and that virtually all routers
are created equal (yes, you have high/medium/low, but, really, since you
have to use high for everything in any reasonable deployment...)

No it doesn't. You can set the router lifetime to zero, which indicates
to the end-node that the RA isn't announcing a default router. In this
case, it may be announcing M/O bit, prefix or other parameters.

132

Just to be clear on this: I was taking issue solely with the idea that
DHCPv6 requires RA. It doesn't.

Regards, K.

133

Actually, it's not pointless at all. The RA system assumes that all routers
capable of announcing RAs are default routers and that virtually all routers
are created equal (yes, you have high/medium/low, but, really, since you
have to use high for everything in any reasonable deployment...)

No it doesn't. You can set the router lifetime to zero, which indicates
to the end-node that the RA isn't announcing a default router. In this
case, it may be announcing M/O bit, prefix or other parameters.

DHCPv6 can selectively give different information to different hosts
on the same wire segment.

RA cannot.

134

Or the default route should point out a different interface.

Think e.g. of DHCP used for a management network. You don't want a
default route, but in case of a routed management network, signal a
set of specific routes.

http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05, there
we go.

Best regards,
Daniel

135

Owen,

Just for grins, let's put some rough math to that assertion. The
average percentage of the Internet reached by a ULA or RFC1918 leak
will be close to:

(1-A)^C

A = the probability of any given organization filtering private
address announcements and/or private address packets at their borders
B = the average width of the Internet in organizations (which should
be slightly higher than the width in ASes)

So filling in example numbers for the equation, if 50% filter
announcements or packets and the Internet is an average of 10
organizations wide then the scope of an address leak is:

(1-0.5)^10 = 0.5 ^ 10 = 0.1% of the Internet reached by the leak.

In that scenario, the leak is in a very real sense one thousandth as
serious as if the leak had been from GUA space which all of the
organizations make an effort to carry. And that's assuming that fully
half the organizations on the Internet just don't bother trying to
filter RFC1918 or ULA use from their public networks.

If 75% filter then a whopping 0.0001% of the Internet is reached by the leak.

Now, if only 10% filter then your leak reaches a largish 6% of the
Internet. That's a worry for someone hoping for some security benefits
to not using GUA space but it's far too little to support this bizarre
concern that ULA space would somehow supplant GUA space on the public
Internet and explode the routers.

Of course, I make no claim to know what the correct two constants are
in that equation. Perhaps the Internet is thinner. Perhaps nobody
filters egress packets despite years of proselytizing. Perhaps the ISP
peering interconnectedness corrupts the combinatorics I used to derive
the equation in a more substantial fashion than is obvious.

Or perhaps your worry about route leakage from non-GUA space really is
as overblown as the math suggests.

Regards,
Bill Herrin

136

Announce your gua and then blackhole it and monitor your prefix.
you can tell if you're leaking. it's generally pretty hard to
tell if you're leaking rfc 1918 since your advertisement may well
work depending on the filters of your peers but not very far.

This is always the argument I hear from corporate customers
concerning wanting NAT. If mistake is made, the RFC 1918 space
isn't routable. They often desire the same out of v6 for that
reason alone.

the rfc 1918 space is being routed inside almost all your adjacent
networks, so if their ingress filtering is working as expected, great,
but you're only a filter away from leaking.

A filter away from leaking to -one- of the millions of entities on the
internet. Two filters away from leaking to two.

This underestimates the transitive property of leakage.

Owen,

Just for grins, let's put some rough math to that assertion. The
average percentage of the Internet reached by a ULA or RFC1918 leak
will be close to:

(1-A)^C

A = the probability of any given organization filtering private
address announcements and/or private address packets at their borders
B = the average width of the Internet in organizations (which should
be slightly higher than the width in ASes)

I'll note that you don't have a B in your equation and didn't define C, so,
I'll presume that C= the average width...

So filling in example numbers for the equation, if 50% filter
announcements or packets and the Internet is an average of 10
organizations wide then the scope of an address leak is:

(1-0.5)^10 = 0.5 ^ 10 = 0.1% of the Internet reached by the leak.

I think your estimation of 50% is highly optimistic. I also think
you underestimate the diameter of the internet, being much
closer to 25 than 10 from what I can see. Filling in more
realistic (based on my observations) numbers of 5% and 25,
my numbers come out as:

(1-0.05)^25 = 0.95 ^ 25 = 0.27 = a little more than 1/4 of the internet.

In that scenario, the leak is in a very real sense one thousandth as
serious as if the leak had been from GUA space which all of the
organizations make an effort to carry. And that's assuming that fully
half the organizations on the Internet just don't bother trying to
filter RFC1918 or ULA use from their public networks.

With more realistic numbers, it's closer to 1/4 of the impact of a leak
from GUA where you both leaked the route and failed your IP
filter and didn't null-route the prefix at your border. (Gee, that seems
like three mistakes you need to make for the GUA problem to take
effect instead of just the "two" you claimed for ULA).

If 75% filter then a whopping 0.0001% of the Internet is reached by the leak.

ROFLMAO... Yeah, and if Ostriches had 15 times the wing surface area they
could probably fly.

Now, if only 10% filter then your leak reaches a largish 6% of the
Internet. That's a worry for someone hoping for some security benefits
to not using GUA space but it's far too little to support this bizarre
concern that ULA space would somehow supplant GUA space on the public
Internet and explode the routers.

ULA won't supplant GUA, it will be much more insidious than that. Most
people will still use GUA for GUA purposes.

However, deliberate routing of ULA will start small and slowly spread
over time like a slow-growing cancer. You won't even really detect it
until it has metastasized to such an extent that nothing can be done
about it.

You can't talk about the impact of an accidental leak and compare that
to the impact of a deliberate choice to do something. They are two
entirely different effects.

Of course, I make no claim to know what the correct two constants are
in that equation. Perhaps the Internet is thinner. Perhaps nobody
filters egress packets despite years of proselytizing. Perhaps the ISP
peering interconnectedness corrupts the combinatorics I used to derive
the equation in a more substantial fashion than is obvious.

I think that the internet is actually much wider and that the actual filtration
rate is much closer to 5%. I also think that the peering combinatorics do
probably corrupt your equation, but, I'm not sure in which direction or
to what extent. It would be pretty hard to estimate, so, I'm willing to
go with it for now.

Or perhaps your worry about route leakage from non-GUA space really is
as overblown as the math suggests.

I'm not worried about leakage. You're claiming that a low probability of
leakage provides a security benefit, I'm claiming that your security benefit
is actually a false sense of security. (i.e. The benefit claimed for ULA
is somewhere between small and non-existent).

In a separate topic, I believe that DELIBERATE routing of ULA will
be a very likely outcome of current policies eventually resulting in
ULA being ubiquitously routed just as GUA is intended to be. This
unfortunate end result of the combination of human nature to do
the expedient rather than the correct will eventually remove any
perceive benefits to ULA and cause additional problems as ULA
becomes a globally routable resource not subject to RIR policy.

The two issues are related, but, very different problems. (Actually,
the first issue isn't really a problem unless you are depending on
ULA to provide some form of security benefit).

In my opinion, the far more secure thing to do is to use GUA.
Put the hosts you want to be reachable from the outside in
specific ranges of your GUA.

For example:

  2620:0db8:532a::/48 Total assignment for end site
  2620:0db8:532a::/56 Space reserved for externally reachable

Configure the following on your border routers:

Routes:
  2620:0db8:532a::/56 dynamic or static routes to correct destinations.
  2620:0db8:532a:100::/55 -> null
  2620:0db8:532a:200::/54 -> null
  2620:0db8:532a:400::/53 -> null
  2620:0db8:532a:800::/52 -> null
  2620:0db8:532a:1000::/51 -> null
  2620:0db8:532a:2000::/50 -> null
  2620:0db8:532a:4000::/49 -> null
  2620:0db8:532a:8000::/48 -> null

Route filters:
  From internal interfaces:
    Accept 2620:0db8:532a::/56 or longer
    Deny 2620:0db8:532a:: ge /48 le /55

Packet filters:
  Stateful (outbound to internet):
    Permit <source match 2620:0db8:532a::/56> any
    Default Deny any any

  Stateful (inbound from internet):
    Permit <specifically intended inbound flows to 2620:0db8:532a::/56>
    Permit <matching outbound state table entry>
    Deny any 2620:0db8:532a::/48
    Default deny inbound

  Static (outbound to internal interfaces)
    permit any 2620:0db8:532a::/56
    deny any any

  Static (inbound from internal interfaces)
    permit <source match 2620:0db8:532a::/56> any
    deny any any

(Assuming a router capable of stateful and static filters
where a packet must be permitted by both in order to be
forwarded. This is the case for JunOS. I'm not sure about
Cisco or others. If you can only do stateless on your router,
then, you lose one layer of defense, but, not all).

Presumably you have stateful firewall(s) inside your border
with appropriate full stateful policies.

Now, in order to reach one of the hosts in the GUA
space being used for the internal-only communications,
one needs to make the following unauthorized or errant
changes:

  1. Override the null route. (either a static route or
      an unauthorized change to the dynamic
      filter + a dynamic route generated by
      or through the firewall).

  2. Override the stateful Packet filter.

  3. Override the Static packet filter.

  4. Permit the flow on the firewall.

Or, the easier approach:

  1. Configure the host with an externally reachable address
    in the public accessible host range.

  2. Plug the host into one of the publicly reachable networks
    rather than an internal network.

  3. Add inbound permits to the stateful packet filter.

  4. Add inbound permits to the firewall.

Eiher way, it takes at least four acts of fat-fingered or malicious
activity on hosts that have a security border role in order to
achieve a meaningful leak, not the single error you claimed.

Owen

137

Which is why all v6 templates really need to get this in as a discard/filter/etc, just as we do with RFC-1918. I'm not saying it is perfect, but based on how much bogon lists have hurt legitimate traffic, we know the templates are at least used.

Jack

138

Just for grins, let's put some rough math to that assertion. The
average percentage of the Internet reached by a ULA or RFC1918 leak
will be close to:

(1-A)^B

A = the probability of any given organization filtering private
address announcements and/or private address packets at their borders
B = the average width of the Internet in organizations (which should
be slightly higher than the width in ASes)

I think your estimation of 50% is highly optimistic. I also think
you underestimate the diameter of the internet, being much
closer to 25 than 10 from what I can see. Filling in more
realistic (based on my observations) numbers of 5% and 25,
my numbers come out as:
(1-0.05)^25 = 0.95 ^ 25 = 0.27 = a little more than 1/4 of the internet.

Owen,

I see. In trying to pick those numbers, my current (today) experience is this:

I filter.
Two of the three ISPs I interact with personally filter.
My employer filters.
Three of the five ISPs they deal with filter.

Total: 7 of 10 filter.

What experience of yours leads you to believe that something closer to
1 in 20 organizations choose to filter out RFC1918 and/or ULA at their
borders? Do *you* filter border-crossing RFC1918 traffic? Does your
employer, HE?

ULA won't supplant GUA, it will be much more insidious than that. Most
people will still use GUA for GUA purposes.
However, deliberate routing of ULA will start small and slowly spread
over time like a slow-growing cancer. You won't even really detect it
until it has metastasized to such an extent that nothing can be done
about it.
I believe that DELIBERATE routing of ULA will
be a very likely outcome of current policies eventually resulting in
ULA being ubiquitously routed just as GUA is intended to be. This
unfortunate end result of the combination of human nature to do
the expedient rather than the correct will eventually remove any
perceive benefits to ULA and cause additional problems as ULA
becomes a globally routable resource not subject to RIR policy.

You need to back that up with something. This sort of thing doesn't
just magically happen. Spin at least one scenario leading there in
which the step-by-step choices by each of the participants are at
least arguably rational.

In my opinion, the far more secure thing to do is to use GUA.
Put the hosts you want to be reachable from the outside in
specific ranges of your GUA.
For example:
Route filters:
From internal interfaces:
Accept 2620:0db8:532a::/56 or longer
Deny 2620:0db8:532a:: ge /48 le /55

Fat finger the second line (interpose the b and the d) and misconnect
one ethernet cable so that your firewall interior protocol can touch
your firewall exterior protocol. In comes a set of formerly interior
routes ranging from /56 to /64, more specific routes that override
your nulls. You're done. Your entire internal network is now
firewall-free on the Internet.

You've never typed in a line wrong in a router config or plugged a
cable in to the wrong jack, right? And you've never tasked network
setup work to a junior engineer whose networking sophistication is
less than your own.

BTW, in your opinionated security process you forgot to install RA
guard. Without RA guard on every switch port that doesn't connect to
an intentional router, some idiot user can plug a 4G modem into their
laptop and every damn device sharing the network will assign itself an
additional GUA address and route through him. Two IPv4 dhcp servers
tended to conflict with each other so the result was an outage. IPv6's
designers considered that a bug and made it go away so that there's a
good chance you won't notice the breach.

We have not yet begun to reach the depths of SLAAC's badness.

Regards,
Bill Herrin

139

>>>
>> Actually, it's not pointless at all. The RA system assumes that all routers
>> capable of announcing RAs are default routers and that virtually all routers
>> are created equal (yes, you have high/medium/low, but, really, since you
>> have to use high for everything in any reasonable deployment...)
>>
>
> No it doesn't. You can set the router lifetime to zero, which indicates
> to the end-node that the RA isn't announcing a default router. In this
> case, it may be announcing M/O bit, prefix or other parameters.
>
DHCPv6 can selectively give different information to different hosts
on the same wire segment.

RA cannot.

That was not the assertion you made.

You said that

"The RA system assumes that all routers

>> capable of announcing RAs are default routers"

and I said, no, that is not the case if you set the RA lifetime to
zero. To cite explicitly, RFC4861 says,

      Router Lifetime
                     16-bit unsigned integer. The lifetime associated
                     with the default router in units of seconds. The
                     field can contain values up to 65535 and receivers
                     should handle any value, while the sending rules in
                     Section 6 limit the lifetime to 9000 seconds. A
                     Lifetime of 0 indicates that the router is not a
                     default router and SHOULD NOT appear on the default

Narten, et al. Standards Track [Page 20]
^L
RFC 4861 Neighbor Discovery in IPv6 September 2007

                     router list. The Router Lifetime applies only to
                     the router's usefulness as a default router; it
                     does not apply to information contained in other
                     message fields or options. Options that need time
                     limits for their information include their own
                     lifetime fields.

I was not making any statements about whether DHCPv6 could be
selective about providing certain options to selected end-nodes.

You might think I'm being overlay pedantic, however changing the
question to then disagree with answer that doesn't agree with yours is
being disingenuous.

>> There are real environments where it's desirable to have a way to tell
>> different clients on a network to use different default gateways or
>> default gateway sets.
>>

I wouldn't necessarily disagree, although in my experience they're
really quite rare, to the point where segmenting them into a separate
subnet, via e.g. a different VLAN, becomes a somewhat better and easier
option.

Regards,
Mark.

140

Actually, it's not pointless at all. The RA system assumes that all routers
capable of announcing RAs are default routers and that virtually all routers
are created equal (yes, you have high/medium/low, but, really, since you
have to use high for everything in any reasonable deployment...)

No it doesn't. You can set the router lifetime to zero, which indicates
to the end-node that the RA isn't announcing a default router. In this
case, it may be announcing M/O bit, prefix or other parameters.

DHCPv6 can selectively give different information to different hosts
on the same wire segment.

RA cannot.

That was not the assertion you made.

You said that

"The RA system assumes that all routers

capable of announcing RAs are default routers"

and I said, no, that is not the case if you set the RA lifetime to
zero. To cite explicitly, RFC4861 says,

Right... I oversimplified the point I was attempting to make and you
called me on it... Move on.

     Router Lifetime
                    16-bit unsigned integer. The lifetime associated
                    with the default router in units of seconds. The
                    field can contain values up to 65535 and receivers
                    should handle any value, while the sending rules in
                    Section 6 limit the lifetime to 9000 seconds. A
                    Lifetime of 0 indicates that the router is not a
                    default router and SHOULD NOT appear on the default

Narten, et al. Standards Track [Page 20]
^L
RFC 4861 Neighbor Discovery in IPv6 September 2007

                    router list. The Router Lifetime applies only to
                    the router's usefulness as a default router; it
                    does not apply to information contained in other
                    message fields or options. Options that need time
                    limits for their information include their own
                    lifetime fields.

I was not making any statements about whether DHCPv6 could be
selective about providing certain options to selected end-nodes.

You might think I'm being overlay pedantic, however changing the
question to then disagree with answer that doesn't agree with yours is
being disingenuous.

There are real environments where it's desirable to have a way to tell
different clients on a network to use different default gateways or
default gateway sets.

I wouldn't necessarily disagree, although in my experience they're
really quite rare, to the point where segmenting them into a separate
subnet, via e.g. a different VLAN, becomes a somewhat better and easier
option.

While I would agree with you operationally, sometimes they involve
software that discovers other devices by broadcast and does not
permit other mechanisms.

I've seen environments where they're able to deal with this in IPv4
because of this flexibility in DHCPv4 and would be limited to static
addressing in IPv6 because it lacks this ability.

Owen