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

[Daryll Swer <[e-mail]>]

> FWIW there is a proposal in the dhc working group to solve this by
registering SLAAC addresses using dhcp. If this would solve your problem,
maybe you could help out with that instead of complaining here.
I was not aware of this particular proposal, until now. Now this, this
looks like a real viable solution vs the NDP Table export or SNMP trap idea.

I will check it out, from a quick glance, it does appear to be in a good
state already from the early draft.

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


On Sun, 24 Dec 2023 at 07:23, Ted Lemon <[e-mail]> wrote:

> FWIW there is a proposal in the dhc working group to solve this by
> registering SLAAC addresses using dhcp. If this would solve your problem,
> maybe you could help out with that instead of complaining here. If it would
> not, then it would be helpful for the working group to understand why not.
>
> Op za 23 dec 2023 om 19:42 schreef Daryll Swer <contact=
> [e-mail]>
>
>> Mark
>>  SLAAC
>> > 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.
>>
>> > 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
>>>>
>>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>