Re: [v6ops] Why should IP networks be different? [DHCP Option 108 Issue with Mac and iOS devices]

[Daryll Swer <[e-mail]>]

>
> Note to everyone else (because I’m sure Nick gets that): please don’t tell
> me how devices with 8K of RAM and 8-bit CPUs running at 4 MHz cannot do
> DHCPv6. Everyone gets that, and nobody in their right might would connect
> those devices to the same network as everything else as they probably
> contain a gazillion other shortcuts (like burned-in admin passwords).
>

Highlighting this again, on this specific aspect in case it was missed in
the discussion:
https://mailarchive.ietf.org/arch/msg/v6ops/23k33gPThhiQvuaUhRuOaAYeCuA/

Okay, what if it was:
> DHCPv6 MUST for non-resource constrained devices (such as modern day
> smartphones, PCs, laptops, network devices etc), but a section for
> exemption to SHOULD for resource constrained devices (such as industrial
> embedded devices and systems, microcontrollers etc) — I don't see any value
> for DHCPv6 on such devices anyway, SLAAC is perfectly fine for such use
> cases.
>
> It's not a perfect solution or compromise, but I would take it. If a vendor
> then, like Google or whoever, refuses to support DHCPv6, we can use the
> “MUST” keyword to apply pressure on them, because how exactly are they
> going to claim for exemption section, when their phones can perform ray
> tracing? I'm sure DHCPv6 requires less code than ray tracing.
>

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://mailtrack.io/link/308a2f91160d898445b3b0991efdc502d5354e10?url=https%3A%2F%2Fwww.daryllswer.com&userId=2153471&signature=d9e6209e6dafd31a>


On Wed, 3 Jan 2024 at 13:38, Ivan Pepelnjak <[e-mail]> wrote:

> Thanks a million for the great summary Nick! While I agree with most of
> what you wrote, you got into a Catch-22 situation:
>
> Folks see a need for tracking a device to a user with IPv6. - I get
> this, I hear the same thing frequently. The commentary slides around
> from a simple need to associate a hardware address with a layer 3
> address to a full on mapping of user to device with a strong
> preference by some to simply mimic what IPv4 does up to and including
> state synchronization and redundancy of operations.
> Personally, I don't think it is realistic to assume that we should
> simply replicate something that exists already. We should aim for
> whatever it is to be better and to address any shortcomings. I am very
> excited about draft-ietf-dhc-addr-notification and *prefix-per-device*
> as a solution set for most of what is discussed here.
>
>
> Let me point out that "prefix-per-device” is even worse (from the
> supporting infrastructure’s perspective) than a mechanism we already have
> (DHCPv6 IA_NA). Not only is the state tracked on the DHCPv6 server, but it
> also needs to be tracked on the first-hop router (a route for the delegated
> prefix), and potentially redistributed into the rest of the network. I’m
> obviously assuming the sane scenario, not devices that grab dozens of IPv6
> addresses just because that was convenient to whoever didn’t want to write
> a bit of an orchestration code to support the in-device networking.
>
> Maybe we should stop pretending that additional layers of abstraction will
> solve the problem, and address the elephant in the room — continuous denial
> of enterprise reality by a single OS vendor.
>
> Note to everyone else (because I’m sure Nick gets that): please don’t tell
> me how devices with 8K of RAM and 8-bit CPUs running at 4 MHz cannot do
> DHCPv6. Everyone gets that, and nobody in their right might would connect
> those devices to the same network as everything else as they probably
> contain a gazillion other shortcuts (like burned-in admin passwords).
>
> On a more positive note, wish you a happy IPv6-enabled 2024!
> Ivan
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>