Re: [v6ops] Implementation Status of PREF64

[David Farmer <[e-mail]>]

On Thu, Sep 30, 2021 at 12:43 AM Lorenzo Colitti <lorenzo=
[e-mail]> wrote:

> On Wed, Sep 29, 2021 at 1:01 AM STARK, BARBARA H <[e-mail]> wrote:
>
>> <bhs> I mostly agree. Unfortunately, some governments are putting
>> pressure on enterprises and government networks (which are just a type of
>> enterprise network) to support IPv6. This is largely due to messaging
>> coming from the IETF. Maybe IETF should produce a Best Practice
>> recommendation that enterprise and government networks not support IPv6
>> until all tools they need to properly secure an IPv6-enabled network are
>> widely available as software updates to legacy equipment.
>>
>
> Do you actually think it's the equipment that's the issue here? Even if
> the equipment isn't capable of logging neighbour table bindings via syslog
> (which most vendors have for a while), scraping ND tables isn't that hard
> to do.
>

The reference you provided is for switches, not routers, yes many people
use them as routers.  *I*'m not aware of most routers logging ND and ARP
without debug level logging which isn't recommended on production routers
running at full tilt.  If I'm wrong about that, I'd love to hear it.

Scraping ND and ARP via SNMP, sucks, and doesn’t scale well, if I remember
correctly you have to fetch individual lines of the table. We found a much
lower impact on the routers using the command line and screen scraping ssh
sessions, yea it's ugly, but it works. We burn a couple of beefy machines
scraping our network, ~4k switched, +15K APs, ~10K L3 interfaces, +150K mac
addresses, with an average of 5 addresses per MAC, not to mention a quite
sizable backend Oracle DB instance to track it all.

I've been asking about telemetry streaming of ND and ARP deltas only, but
haven't been getting traction on that, but I haven't pushed too hard
either, we have had other priorities with our vendors.

I think some open-source tools for ND and ARP scraping aimed at
medium-sized enterprise networks with a hundred switches or less and a few
thousand clients or smaller would go a long way to planting new habits in
the IT industry.

I think the issue is more around operational familiarity and the idea that
> because we do things this way in IPv4 we must to do them the same way in
> IPv6 as well.
>

Yes, that is a big part of it. But, with the added frustration, that by
calling it DHCPv6, we very much give the allusion that you can just do
things the same way you did them with IPv4. So can you really blame people
for drinking the kool-aid? Furthermore, DHCPv4 and DHCPv6 are really quite
different things, and it isn't the "easy button" that they thought they
had. Throw in the fact most IT shops barely keep their heads above water,
strategic thinking becomes pretty rare and a luxury most organizations do
have. Then the last straw, Android doesn't support DHCPv6, any doubt why
IPv6 deployment is lagging in enterprises?

Thanks.
-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================