Re: [v6ops] DHCP Option 108 Issue with Mac and iOS devices

[Daryll Swer <[e-mail]>]

Soni

I explained the problem with SLAAC logging in the other email to Jen, even
if we do use NDP Table. If you still think NDP table export with SLAAC is a
financially smart idea in small (to medium-sized even) business, be my
guest and go ahead and do it ;)

--
Sent from my iPhone


On Fri, 22 Dec 2023 at 4:37 AM, Soni "They/Them" L. <[e-mail]>
wrote:

> 1. Being completely honest we never looked if logging MAC addresses
> alongside IP addresses is standard among the industry, we don't really have
> experience in the enterprise IT network area, it just seems like the
> obvious solution to us and it's the solution we'd deploy if we were making
> a custom solution for it. We mostly just work with OS dev stuff (and still
> trying to get wasm to ship "IPv6-only networking in userspace" which is
> even more cursed than some of the other stuff we've brought up on this
> list)...
> 2. You can argue TLS is obscurity since 256-bit keys are finite after all.
> Technically all encryption is obscurity really, it's just generally
> infeasible to break it. So no, that's... really not a good argument.
>
> On 2023-12-21 19:53, Daryll Swer wrote:
>
> Soni
>
> Since apparently you've solved SLAAC logging issues for enterprise.
>
> 1. Share with us all the steps required for packet-logging free method to
> track SLAAC address in an enterprise network. We need the steps for common
> market vendors such as Juniper, MikroTik, Arista etc. I'm listening.
> Preferably it be an open standard/protocol/tooling that's widely available
> in the industry and one that's well supported by all major network vendors.
>
> 2. > hiding the exact number of devices in a network
> Obscurity is not security. This is the same argument and logic IPv4 NAT
> users make. "Oh but I'm hiding 100 hosts behind single public IP".
>
> --
> Sent from my iPhone
>
>
> On Fri, 22 Dec 2023 at 4:06 AM, Soni "They/Them" L. <
> [e-mail]> wrote:
>
>> Nah, locally you'd be using MAC addresses to identify the device. The
>> Ephemeral IPv6 is just there to help with one aspect of IP address privacy
>> (hiding the exact number of devices in a network by making remote servers
>> think there are a lot more of them, and, while at it, also breaking some
>> login forms for the fun of it).
>>
>>
>> On 2023-12-21 19:27, Daryll Swer wrote:
>>
>> Soni
>>
>> Ah, encouraging cybercrime through multiple randomly generated IPv6
>> source IPs, are we? Fantastic idea. I'll be sure to share this explanation
>> of yours with law enforcement when they come asking for logs. And point
>> them to this mailing list on why I failed to provide reliable and
>> consistent logs for my SLAAC VLAN.
>>
>> I'm not interested in making it easier for cybercrime to occur through my
>> network as origin, therefore comes the need for DHCPv6.
>>
>> In the past with early days of CGNAT, it took quite some time and
>> pressure from law enforcement before deterministic NAT logging was drafted
>> at the IETF. If this pattern holds true, it's only a matter of time before
>> similar pressure hits IPv6 as IPv6 adoption is increasing. I don't think
>> the IETF will draft NAT66 deterministic logging. I only see ia_na as the
>> viable option.
>>
>>
>> --
>> Sent from my iPhone
>>
>>
>> On Fri, 22 Dec 2023 at 3:41 AM, Soni "They/Them" L. <
>> [e-mail]> wrote:
>>
>>>
>>>
>>> On 2023-12-21 18:59, Daryll Swer wrote:
>>>
>>> We're going in circles here, hashing the same thing over and over again.
>>> I genuinely do not understand why the decision makers in the IETF with
>>> respect to SLAAC/DHCPv6 don't seem to grasp the reality that SLAAC isn't a
>>> one size fits all.
>>>
>>> A major pain for operators (like me) is exactly this type of debate
>>> (going in circles) in IETF mailing lists. This is the real reason why, we
>>> don't have a lot of operators on these lists.
>>>
>>> A ia_na only VLAN is probably something I wouldn't do because of the
>>> CLAT issues at this point in time. What I would do is ia_na + ia_pd, if
>>> we're talking something like campus Wi-Fi or public Wi-Fi, I would likely
>>> opt for /128 ia_na + /127 ia_pd (need to check if all vendors supports
>>> this, MikroTik does if I remember correctly). There's no reason for me to
>>> give a /48 per thousands of mobile phone users connected over Wi-Fi.
>>>
>>> The need for ia_na isn't really driven from IPv4 thinking. I'm not about
>>> to deploy NAT66. The need for ia_na is for auditing and making it easier to
>>> provide logs for security incidents not only for internal company but also
>>> to law enforcement. I shouldn't need to perform gymnastics with SLAAC in an
>>> enterprise network to figure out which device used which /128 that law
>>> enforcement is asking for information about.
>>>
>>> By definition SLAAC is stateless. And we need state tracking (state of
>>> address assignment not CLAT).
>>>
>>> As far as "security" is concerned, we normally deploy stateful firewall
>>> anyhow (which permits ICMPv6 through and through at the least), to protect
>>> the clients.
>>>
>>> Regarding, privacy, come on, are you really telling me Google analytics
>>> and big tech analytics can't tracked me if I use SLAAC? They can, via
>>> system/OS/Device and browser fingerprinting, not even just cookies. They've
>>> been doing this for decades, for devices that switch between "Wi-Fi" and
>>> cellular for instance.
>>>
>>> This strange idea that analytics only work on static IPs (and therefore
>>> dynamic IPs give privacy) is something I can never understand.
>>>
>>>
>>> It's not "a" dynamic IP that gives you privacy. It's *multiple*.
>>>
>>> Are you familiar with the concept of "poisoning" where you fill the data
>>> with extra, autogenerated data?
>>>
>>> For example, filling up a library with AI-generated books, or filling up
>>> a search history with markov chain search queries, or sending "You have
>>> been blocked" posts to mastodon instances you have... blocked.
>>>
>>> It makes it harder to find real books, it makes it harder to identify
>>> real queries, it prevents real posts from getting federated through
>>> third-parties.
>>>
>>> The same is true for using lots and lots and lots of IPv6. The more IPv6
>>> per second, the harder it is to identify the device.
>>>
>>>
>>>
>>> --
>>> Sent from my iPhone
>>>
>>>
>>> On Fri, 22 Dec 2023 at 3:13 AM, Brian E Carpenter <
>>> [e-mail]> wrote:
>>>
>>>> On 22-Dec-23 08:45, Daryll Swer wrote:
>>>> >  > E.g., the Google IPv6-mostly deployment Jen has been talking about
>>>> over the years enables SLAAC
>>>> >
>>>> > The decision should be left up to the network operator on whether to
>>>> use DHCPv6 or SLAAC or both. But unfortunately even if an operator wants to
>>>> use DHCPv6 they can't if they have Android clients.
>>>> >
>>>> > *Why is Google allowed to dictate how other operators should deploy
>>>> IPv6? Are they the IPv6 police?*
>>>>
>>>> Welcome to capitalism. The market has chosen to buy a lot of Android
>>>> devices. That's all.
>>>>
>>>> >
>>>> > As for preference, just search up "DHCPv6 enterprise", you can find
>>>> many operators who discussed this very issue or preference over the years.
>>>> I'm surprised you never encountered enterprise folks who explicitly and
>>>> vocally prefers DHCPv6.
>>>>
>>>> They tend to, because they wish to determine the relationship between a
>>>> device and its IP address in advance, as they've been doing for years.
>>>> Whether this is actually necessary is another question. With SLAAC, this
>>>> relationship can be logged and determined retrospectively. I've never been
>>>> quite clear why this is problematic, for either audit purposes or incident
>>>> management. Isn't there just a false assumption that the way addresses had
>>>> to be managed for IPv4 is also the way it must be done for IPv6?
>>>>
>>>>      Brian
>>>>
>>>> >
>>>> > It doesn't take very long to figure out "general" preference just by
>>>> reading this thread top to bottom:
>>>> > https://issuetracker.google.com/issues/36949085 <
>>>> https://issuetracker.google.com/issues/36949085>
>>>> >
>>>> > Another source:
>>>> >
>>>> https://www.nullzero.co.uk/android-does-not-support-dhcpv6-and-google-wont-fix-that/
>>>> <
>>>> https://www.nullzero.co.uk/android-does-not-support-dhcpv6-and-google-wont-fix-that/
>>>> >
>>>> >
>>>> > /Do I really need to share 100 links here on this mailing list, of
>>>> folks who've been complaining about this Android DHCPv6 issue for the last
>>>> 10+ years?/
>>>> >
>>>> > Every single enterprise folk I know prefers stateful DHCPv6, but are
>>>> often if not always stuck with SLAAC.
>>>> >
>>>> > --
>>>> > Sent from my iPhone
>>>> >
>>>> >
>>>> > On Fri, 22 Dec 2023 at 12:59 AM, Ted Lemon <[e-mail] <mailto:
>>>> [e-mail]>> wrote:
>>>> >
>>>> >     I think your stated preference says more about you than about
>>>> enterprise networks in general. E.g., the Google IPv6-mostly deployment Jen
>>>> has been talking about over the years enables SLAAC.
>>>> >
>>>> >     I don't mean that you're wrong to have this preference, just that
>>>> it seems clearly wrong to generalize from your preference (for which you
>>>> haven't stated a reason for us to consider) to all enterprise settings. Of
>>>> the two enterprise settings about which I have personal knowledge, zero
>>>> have deployed DHCPv6. Deploying DHCPv6 requires extra work and extra cost.
>>>> It seems absurd to think that this would be peoples' default choice.
>>>> >
>>>> >     On Thu, Dec 21, 2023 at 2:17 PM Daryll Swer <contact=
>>>> [e-mail] <mailto:[e-mail]>>
>>>> wrote:
>>>> >
>>>> >          > Dual-stack in the edge needs to go away.
>>>> >
>>>> >         Very likely we have different definitions of an edge router.
>>>> But either way, I'm happy to do v6-only network if Android and/or other
>>>> popular end-user OSes supported DHCPv6 to the fullest extent.
>>>> >
>>>> >         For me SLAAC should be limited largely, by default to home
>>>> networks, SOHO etc. In an enterprise or ISP network, I think most operators
>>>> would prefer DHCPv6 stateful, including me.
>>>> >
>>>> >         I would prefer stateful DHCPv6 even in my own home lab. But
>>>> alas, Android devices prevents that, at least on the same SSID, oh well,
>>>> more reasons to buy an iOS device - Why waste money on a vendor with
>>>> incomplete IPv6 feature set...
>>>> >
>>>> >         *--*
>>>> >         Sent from my iPhone
>>>> >
>>>> >
>>>> >         On Fri, 22 Dec 2023 at 12:18 AM, Gert Doering <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>> >
>>>> >             Hi,
>>>> >
>>>> >             On Thu, Dec 21, 2023 at 10:22:00PM +0530, Daryll Swer
>>>> wrote:
>>>> >              > > Not wanting to operate a dual-stack network is less
>>>> an "IPv6 purist"
>>>> >              > thing as more "pure lazyness".  Dual-stack is,
>>>> basically, more work to set
>>>> >              > up and maintain things, for very little gain.
>>>> >              >
>>>> >              > Dual stack on the layer 3 devices in the access layer
>>>> does not imply dual
>>>> >              > stack network-wide, you can use IPv6-only PtP links
>>>> with IPv4 routed over
>>>> >              > the IPv6 next-hop, this limits dual stack only on your
>>>> layer 3
>>>> >              > sub-interface VLANs on each layer 3 devices in the
>>>> access layer.
>>>> >
>>>> >             Yes, but backbone links are an order of magnitude less
>>>> than access VLANs,
>>>> >             and much easier to (auto-)provision and monitor than
>>>> "random access
>>>> >             networks with random clients, random applications, and
>>>> random failure
>>>> >             modes hiding real issues".
>>>> >
>>>> >             Dual-stack in the edge needs to go away.
>>>> >
>>>> >             Gert Doering
>>>> >                      -- NetMaster
>>>> >             --
>>>> >             have you enabled IPv6 on something today...?
>>>> >
>>>> >             SpaceNet AG                      Vorstand: Sebastian v.
>>>> Bomhard, Michael Emmer
>>>> >             Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A.
>>>> Grundner-Culemann
>>>> >             D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>>>> >             Tel: [phone]         USt-IdNr.: DE813185279
>>>> >
>>>> >
>>>>  131829f8f8575132ef0687e1489e7952ad119c16​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​
>>>> _______________________________________________
>>>> >
>>>> >
>>>> >         v6ops mailing list
>>>> >         [e-mail] <mailto:[e-mail]>
>>>> >         https://www.ietf.org/mailman/listinfo/v6ops <
>>>> https://www.ietf.org/mailman/listinfo/v6ops>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > v6ops mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>>> _______________________________________________
>>> v6ops mailing [e-mail]://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>
>