4 ms·

in general, I agree 100% with you > With sane defaults the only thing leaked is the IP address, which is already public (same as IPv4 with NAT.) Compared to v

by pilif 11y ago

in general, I agree 100% with you > With sane defaults the only thing leaked is the IP address, which is already public (same as IPv4 with NAT.) Compared to v4 NAT though, this will leak an address per device behind the firewall whereas before all these devices would not have been distinguishable. This is why devices started to create a whole lot of temporary v6 addresses, but this causes problems for some stateful firewalls as networks grow and the amount of addresses explodes.

zAy0LfpBZLC8mAC 11y ago
> Compared to v4 NAT though, this will leak an address per device behind the firewall whereas before all these devices would not have been distinguishable. ... just that they aren't really indistinguishable anyway. From cookies to TLS session cookies or session identifiers to specific TCP stack behaviour, it's usually quite easy to distinguish devices behind a NAT. > This is why devices started to create a whole lot of temporary v6 addresses, but this causes problems for some stateful firewalls as networks grow and the amount of addresses explodes. No, a stateful firewall keeps state per connection, not per address, the number of distinct addresses is of no consequence.
- deleted 11y ago
  [deleted]
- pilif 11y ago
  > No, a stateful firewall keeps state per connection, not per address, the number of distinct addresses is of no consequence. which is all well until it isn't: http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ http://blog.bimajority.org/2014/09/05/the-network-nightmare-...
  - darkr 11y ago
    That blog post was referencing issues with FIB/TCAM/multicast state table exhaustion on switches with a small entry limit (3000), brought on by nodes with lots of IPv6 addresses, each with their own multicast group. All of the protocols involved in this are mostly contained within the same layer 2 domain. A "stateful firewall" is generally a firewall that is tracking TCP and UDP packets (i.e L4 and above), so should be unconcerned with anything operating below this layer[1]. A TCP connection is a TCP connection whether running over IPv4 or IPv6. [1]: Things become more convoluted when you have "switches" providing L3 or above functionality, but the problem referenced really is at the switching layer.

by pilif 11y ago

zAy0LfpBZLC8mAC 11y ago

> Compared to v4 NAT though, this will leak an address per device behind the firewall whereas before all these devices would not have been distinguishable. ... just that they aren't really indistinguishable anyway. From cookies to TLS session cookies or session identifiers to specific TCP stack behaviour, it's usually quite easy to distinguish devices behind a NAT. > This is why devices started to create a whole lot of temporary v6 addresses, but this causes problems for some stateful firewalls as networks grow and the amount of addresses explodes. No, a stateful firewall keeps state per connection, not per address, the number of distinct addresses is of no consequence.

deleted 11y ago
[deleted]
pilif 11y ago
> No, a stateful firewall keeps state per connection, not per address, the number of distinct addresses is of no consequence. which is all well until it isn't: http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/ http://blog.bimajority.org/2014/09/05/the-network-nightmare-...
- darkr 11y ago
  That blog post was referencing issues with FIB/TCAM/multicast state table exhaustion on switches with a small entry limit (3000), brought on by nodes with lots of IPv6 addresses, each with their own multicast group. All of the protocols involved in this are mostly contained within the same layer 2 domain. A "stateful firewall" is generally a firewall that is tracking TCP and UDP packets (i.e L4 and above), so should be unconcerned with anything operating below this layer[1]. A TCP connection is a TCP connection whether running over IPv4 or IPv6. [1]: Things become more convoluted when you have "switches" providing L3 or above functionality, but the problem referenced really is at the switching layer.