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

[Daryll Swer <[e-mail]>]

Mark

> Reality is that you're not being objective.
The fact that you think I am the *only* person, in the market, who prefers
*stateful* addressing (whether that's DHCPv6 or something else), shows that
you have are not being objective yourself. Ground reality is,
enterprise/service providers prefer stateful addressing, whether you like
it or not. You can keep pushing for enterprise stateless-only addressing
for IPv6, and end up wondering why IPv6 adoption is snail-paced in
enterprise.

> You are ignoring existing commercial solutions to the problem you claim
to have because they don't require DHCPv6, and work with any of the IPv6
address configuration methods.
> You are resorting to non-technical criticisms ("layer 8 problems", secret
"agendas", "obsessions") because people aren't just going to accept what
you think is the only solution.
You still ignored the *fact* that Google enterprise cloud uses DHCPv6,
still ignored the storage cost issue that I keep mentioning multiple times,
still ignored the vendor-specific only solution having limitations, even
though the very same solution/blog link you shared, leads straight to the
vendor page that explicitly mentions the limitations of SLAAC/NDP based
tracking — If these points/issues are what you call “non-technical”
criticisms, then, more power to you, Mark. If this is not being subjective,
I don't know what is.

The proposal, that Ted shared, however, is far, far more viable and
potentially adoptable for enterprise, than your proposed SNMP Trap or
vendor-specific only solution(s):
https://datatracker.ietf.org/doc/html/draft-wkumari-dhc-addr-notification

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


On Sun, 24 Dec 2023 at 09:30, Mark Smith <[e-mail]> wrote:

>
>
> On Sun, 24 Dec 2023, 11:42 Daryll Swer, <[e-mail]> wrote:
>
>> Mark
>>
>> > State synchronisation is hard.
>> It wouldn't be so hard if DHCPv6-related improvements were allowed to
>> come to fruition in the past 10 years, should SLAAC agenda not exist.
>>
>
> There is no SLAAC "agenda".
>
> Nobody here has stopped the dhc WG working in DHCPv6 state
> synchronisation. It's not an easy problem.
>
> If you think there is a SLAAC agenda, as I am somebody who thinks SLAAC is
> a better solution to address assignment and configuration, for the
> *technical* reasons I've provided, tell me what I'm going to get out
> promoting SLAAC over DHCPv6?
>
> Nobody is paying me to have that opinion. I'm not selling any SLAAC based
> services that are making me money.
>
> Reality is that you're not being objective. You will only accept a DHCPv6
> based solution, even though it doesn't actually properly and fully solve
> the audit/security problem you claim to have.
>
> You are resorting to non-technical criticisms ("layer 8 problems", secret
> "agendas", "obsessions") because people aren't just going to accept what
> you think is the only solution. (I did it with "Big-SLAAC" cynically to
> show it's easy to do.)
>
> You are ignoring existing commercial solutions to the problem you claim to
> have because they don't require DHCPv6, and work with any of the IPv6
> address configuration methods.
>
> The best solution to a problem should satisfy the requirements is the best
> possible way, with the least drawbacks and trade offs. Best solutions is my
> agenda.
>
> That demands not being obsessive and religious about a preferred solution
> such that you ignore other better solutions.
>
> An IP-addresses-in-use solution that works with all of the methods that
> can be used to assign or configure IPv6 addresses on a host is objectively
> a better solution than one that depends on one of the IPv6 address
> assignment and configuration methods, and ignores the others ... unless of
> course you have a subjective agenda for that single IPv6 address assignment
> and configuration method.
>
>
>
>> > Another reason is fate sharing.
>> >
>> > A third reason is overhead of running a database server to allocate
>> addresses.
>> >
>> > A forth reason is running heavier weight clients to do database
>> transactions.
>> >
>> > SLAAC moves the processing and data that would be performed and stored
>> on a DHCPv6 server and distributes that per host processing and data to the
>> individual hosts.
>> >
>> > That means no requirement for a centralised database, nor any database
>> synchronisation requirements for redundancy.
>> >
>> > That means that failure of a host only affects the addressing state if
>> that host itself. Hosts don't share any addressing system fate with each
>> other or a database server.
>>
>> All trade-offs, a lot of enterprises are willing to make. Who exactly are
>> you (all the SLAAC agend-ists) to try to tell money-making businesses
>> globally, on how they should operate their business from a network
>> standpoint? The decision on the 'how' should be made by the respective
>> business as they see fit to match their technical and/or financial
>> requirements.
>>
>> SLAAC is not a one-size fits all solution. There's no such thing as a
>> “one-size fits all solution”.
>>
>> > Those are the technical benefits of a stateless address allocation
>> scheme
>> Financial benefits > technical benefits when decisions are required to be
>> made. Businesses operate on Excel sheets, not SLAAC vs DHCPv6 route count
>> in the routing table.
>>
>> Try deploying your SLAAC-based purist ideology in enterprises and “public
>> access networks” in economies like mine, let me know how it goes:
>> 1. Financially
>> 2. Technical scalability of vendor-specific implementations (also ties to
>> #1)
>> 3. All and any layer 8 overhead that comes with it
>>
>> All I see is Ivory Tower outlook-oriented arguments…
>>
>> You, apparently, missed the vendor warnings (“Problem 2”), storage cost
>> issue (“Problem 3”) and the fact that Google enterprise Cloud uses
>> DHCPv6 that I mentioned here
>> <https://mailarchive.ietf.org/arch/msg/v6ops/DFlzSXGxOldd-rK9kUz3FofLS0o/>
>> .
>>
>> *--*
>> Best Regards
>> Daryll Swer
>> Website: daryllswer.com <https://www.daryllswer.com>
>>
>>
>> On Sun, 24 Dec 2023 at 05:52, Mark Smith <[e-mail]> wrote:
>>
>>>
>>>
>>> On Sun, 24 Dec 2023, 10:23 Daryll Swer, <contact=
>>> [e-mail]> wrote:
>>>
>>>> Brian
>>>>
>>>> Yeah, you're spot on, at least for certain economies.
>>>>
>>>> I should note that in my economy, “public access network” or “public
>>>> Wi-Fi” are required by law to take your mobile phone number and/or
>>>> government issued ID. I.e., you can't access the internet without verifying
>>>> the entered phone number through OTP or without the government issued ID.
>>>>
>>>> Now you might say, but phone numbers can be burners, not quite. Not in
>>>> my country, any more, due to various terrorist attacks from 2000s-2010s
>>>> era, that heavily relied on burner numbers to coordinate, the government
>>>> has made it virtually if not outright illegal to get a burner number.
>>>> Essentially, one cannot obtain a SIM card or e-SIM without government
>>>> issued ID, prior to 2010s era.
>>>>
>>>> This whole logging situation is complex enough as it is even with IPv4
>>>> (hello CGNAT), I don't know why the IETF insists on making it more
>>>> complicated with IPv6 with this “stateless” obsession of address
>>>> assignments.
>>>>
>>>
>>> You yourself have said at least one reason.
>>>
>>> State synchronisation is hard.
>>>
>>> Another reason is fate sharing.
>>>
>>> A third reason is overhead of running a database server to allocate
>>> addresses.
>>>
>>> A forth reason is running heavier weight clients to do database
>>> transactions.
>>>
>>> SLAAC moves the processing and data that would be performed and stored
>>> on a DHCPv6 server and distributes that per host processing and data to the
>>> individual hosts.
>>>
>>> That makes it scale.
>>>
>>> That means no requirement for a centralised database, nor any database
>>> synchronisation requirements for redundancy.
>>>
>>> That means that failure of a host only affects the addressing state if
>>> that host itself. Hosts don't share any addressing system fate with each
>>> other or a database server.
>>>
>>> Those are the technical benefits of a stateless address allocation
>>> scheme, which is why IPv4 before Ethernet had one, XNS had one, IPX had
>>> one, AppleTalk had one, CLNS had one, DecNET had one, Banyan Vines had one
>>> ...
>>>
>>> IPv4, post Ethernet, is the only layer 3 protocol that has a
>>> centralised, database driven address allocation protocol, and the origins
>>> of that can be tied to Ethernet addresses not being small enough to embed
>>> in the host portions of IPv4 addresses, unlike earlier layer 2 protocols
>>> such as BBN-1822/ARPANET and AUTODIN II.
>>>
>>> Address Mappings
>>> https://datatracker.ietf.org/doc/html/rfc796
>>>
>>>
>>> Regards,
>>> Big-SLAAC*
>>>
>>>
>>> *not affiliated with Big-Pharma
>>>
>>>
>>>
>>>> *--*
>>>> Best Regards
>>>> Daryll Swer
>>>> Website: daryllswer.com
>>>> <https://mailtrack.io/link/85f7534d570a5cdaff771e36c5c90abb833765e9?url=https%3A%2F%2Fwww.daryllswer.com&userId=2153471&signature=9badf9a5c38b04c8>
>>>>
>>>>
>>>> On Sun, 24 Dec 2023 at 02:21, Brian E Carpenter <
>>>> [e-mail]> wrote:
>>>>
>>>>> On 24-Dec-23 02:58, Daryll Swer wrote:
>>>>> >  > I find it truly amazing how much energy is invested in approaches
>>>>> to work around the shortcomings of SLAAC, just because "DHCPv6 does not fit
>>>>> the architecture". Maybe the architecture is just... bad?  And this is one
>>>>> of the reasons
>>>>> >
>>>>> > It looks like we'll need to wait for law enforcement pressure to
>>>>> start piling up on IPv6-origin cybercrimes.
>>>>>
>>>>> I think there's a general failure to recognize that corporate networks
>>>>> and public-access networks are deeply different in this respect. (That
>>>>> dichotomy is over-simplified, but never mind for now.)
>>>>>
>>>>> If a bad actor drops into a public-access network, commits their
>>>>> crime, and goes away, any logging that the network has done is pretty
>>>>> useless - somebody with a variable MAC address appeared, grabbed an IP
>>>>> address for half an hour, and then vanished; that MAC address will never be
>>>>> seen again, the IP addresses might serve to identify the geographical
>>>>> location (modulo VPN usage), but the forensic evidence is pretty much
>>>>> useless. So SLAAC is fine for everybody; there's nothing to be gained from
>>>>> DHCP. (Alternatively, you can describe exactly the same scenario as
>>>>> protecting the privacy and civil rights of the person.)
>>>>>
>>>>> On a corporate network whose operator has financial, civil and
>>>>> criminal liability to consider, this is completely unacceptable. As Daryll
>>>>> pointed out, it's the "stateless" in SLAAC that's the problem.
>>>>>
>>>>> Two scenarios, two solutions.
>>>>>
>>>>>      Brian
>>>>>
>>>>>
>>>>> > When that happens, it'll put pressure on these enterprises, the
>>>>> enterprises will put pressure on the vendors, the vendors will come to
>>>>> these IETF mailing lists. Perhaps then, will the SLAAC agend-ists get off
>>>>> their Ivory Towers, come down to the ground reality and patch DHCPv6
>>>>> related issues or derive a completely new protocol/standard for stateful
>>>>> IPv6.
>>>>> >
>>>>> > As of now, even some recent big profile crimes done by ATPs, were
>>>>> funnily enough, largely, IPv4-only (from the attacker's side). But, nothing
>>>>> lasts forever, only a matter of time before the criminals learn IPv6,
>>>>> probably use SLAAC to their advantage if anything.
>>>>> >
>>>>> > *--*
>>>>> > Best Regards
>>>>> > Daryll Swer
>>>>> > Website: daryllswer.com <
>>>>> https://mailtrack.io/link/b50e45b18766146001d8eb00efbd0f9b7e027202?url=https%3A%2F%2Fwww.daryllswer.com&userId=2153471&signature=1d0a6ca56ace57cf
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Sat, 23 Dec 2023 at 15:41, Gert Doering <[e-mail] <mailto:
>>>>> [e-mail]>> wrote:
>>>>> >
>>>>> >     Hi,
>>>>> >
>>>>> >     On Sat, Dec 23, 2023 at 01:29:12PM +1100, Mark Smith wrote:
>>>>> >      > Routers could report ND cache entry creation via SNMP traps
>>>>> etc.
>>>>> >
>>>>> >     Note the "could" here.  Some might actually do, most don't.
>>>>> >
>>>>> >     Is there an RFC that requires router vendors to do that?
>>>>> >
>>>>> >      > SAVI validates IPv6 addresses assigned through multiple
>>>>> mechanisms, so
>>>>> >      > naturally it would be possible to add reporting of SAVI
>>>>> events to
>>>>> >      > implementations.
>>>>> >      >
>>>>> >      > RFC 8074, "Source Address Validation Improvement (SAVI) for
>>>>> Mixed
>>>>> >      > Address Assignment Methods Scenario".
>>>>> >
>>>>> >     Any vendor actually implementing this?
>>>>> >
>>>>> >     I find it truly amazing how much energy is invested in
>>>>> approaches to
>>>>> >     work around the shortcomings of SLAAC, just because "DHCPv6 does
>>>>> not
>>>>> >     fit the architecture".
>>>>> >
>>>>> >     Maybe the architecture is just... bad?  And this is one of the
>>>>> reasons
>>>>> >     why people do not adopt IPv6 in a timely fashion?
>>>>> >
>>>>> >     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
>>>>> >
>>>>> >     _______________________________________________
>>>>> >     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 list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>