IPv6 uptake (was: The Reg does 240/4)

Sat Feb 17 01:22:01 UTC 2024

On 2/16/24 5:05 PM, William Herrin wrote:
> On Fri, Feb 16, 2024 at 3:13 PM Michael Thomas <mike at mtcc.com> wrote:
>> If you know which subnets need to be NAT'd don't you also know which
>> ones shouldn't exposed to incoming connections (or conversely, which
>> should be permitted)? It seems to me that all you're doing is moving
>> around where that knowledge is stored? Ie, DHCP so it can give it
>> private address rather than at the firewall knowing which subnets not to
>> allow access? Yes, DHCP can be easily configured to make everything
>> private, but DHCP for static reachable addresses is pretty handy too.
> Hi Mike,
>
> Suppose I have a firewall at 2602:815:6000::1 with an internal network
> of 2602:815:6001::/64. Inside the network on 2602:815:6001::4 I have a
> switch that accepts telnet connections with a user/password of
> admin/admin. On the firewall, I program it to disallow all Internet
> packets to 2602:815:6001::/64 that are not part of an established
> connection.
>
> Someone tries to telnet to 2602:815:6001::4. What happens? Blocked.
>
> Now, I make a mistake on my firewall. I insert a rule intended to
> allow packets outbound from 2602:815:6001::4 but I fat-finger it and
> so it allows them inbound to that address instead. Someone tries to
> telnet to 2602:815:6001::4. What happens? Hacked.

Yes, but if the DHCP database has a mistake it's pretty much the same 
situation since it could be numbered with a public address. For both you 
can have the default as "reject" or "accept" -- that's just a default 
and depends on how you want to manage your network.

NAT is not without its own set of problems, so if this boils down to a 
subnet management issue there are obviously ways to deal with that to 
avoid NAT's problems. Both DHCP and firewall configs don't have to be 
the ultimate source of truth about any of this. And that's likely a Good 
Thing since you want them to be pretty much as fungible and replaceable 
as possible. If you're exposed to fat fingers for either, you're 
probably already in trouble. Something in the management plain is far 
more likely to care about this kind of thing than hardware vendors who 
see that as a cost center with predictably shitty implementations.

Mike