5 ms·

Curious why you think that? IPv4 + ARP + DHCP + NAT has a lot more baggage. IPv6 and a stateful firewall gets the job done quite well, without the address exhau

Curious why you think that? IPv4 + ARP + DHCP + NAT has a lot more baggage. IPv6 and a stateful firewall gets the job done quite well, without the address exhaustion.

axytol 3y ago
Not OP and certainly not in the anti-IPv6 camp. I'm wondering though: could you build a case that under IPv4, a misconfigured NAT would only result in lost connectivity for nodes behind the router, while for IPv6 a misconfigured firewall and worse triggered through a vulnerability, would then result in protected nodes being exposed? I know NAT-PMP (port mapping) vulnerabilities exist, allowing external actors to set port mappings to hosts behind NAT, but this seems a bit harder to exploit than a bypassed firewall.
- ianlevesque 3y ago
  I don't think that's true in general because each of these end-user routers have their own sharp edges. IPv4 consumer routers have a DMZ option which would, for at least 1 device, be the same as taking down your stateful firewall. Also, thankfully, in all of the examples I've seen in the wild, the stateful firewall was just on by default, much as NAT is on by default. In both cases you are taking steps to compromise your own security, that most people won't bother to do. Finally, the risk to an individual machine 'loose on the internet' is lower than its ever been because Windows has for years enabled a firewall by default on its own, and macOS doesn't expose any open ports by default either. That does leave printers, IoT devices, and the like, but now we're really pretty far into the weeds of lots of non-default customization combined with individual CVEs in non-computing hardware.
  - iso1631 3y ago
    If my firewall failed then the packet won't reach my 192.168.0.1 DMZ server as it will likely never be translated from my real 12.34.56.78 IP address (as the translation would be part of that stateful firewall) Sure there are exceptions, but you are massively reducing your risk by not having your toaster having a public address by default and having something actively have to translate it to a public address
Quekid5 3y ago
I think it's probably just the fact that the IPv4 stack has just received a lot more hardening because it's deployed everywhere (by necessity)... and IPv4 has had a 15+ years lead over IPv6 on that whole hardening thing because it came later and a time where IPv4 was already pretty well established.
tedunangst 3y ago
How about the fact that half the RFCs you were supposed to implement 20 years ago have been superseded by RFCs saying do not implement?
- ianlevesque 3y ago
  Not sure why you are being downvoted, if there was a pile of churn in IPv6 recommendations I'm curious about them.
  - Macha 3y ago
    * SLAAC with MAC addresses -> Stable privacy addresses * fec0:: site local addresses -> ULAs * No DHCP handing out addresses -> DHCPv6 * "IPv4 compatible" ::<IPv4 address> -> "IPv4 mapped" ::ffff:<IPv4 address> * 6to4 -> Just use dual stack * ip6.int RDNS -> ip6.arpa
    - tedunangst 3y ago
      RH0 was so bad it should count twice.
ploxiln 3y ago
Ah, where to start ... 128-bit addresses are annoyingly huge. 64 bits would have been enough. Even 48 bits gives you 64 thousand times the ipv4 address space. 64 bits gives you 4 billion times the ipv4 address space. In practice the 128-bit address space has been used as wastefully as it allows e.g. giving a whole /64 to a single server (4 billion ipv4 internets to just a single server!) Link-local addresses being automatically assigned to every interface, as they are with ipv6 (fe80::xxxx:xxxx:xxxx:xxxx) means that you need to use an interface index or name to distinguish them, so now addresses sometimes need a "%XX" added on the end, e.g. fe80::1ff:fe23:4567:890a%eth2 (this is specific to the source machine, not dest ...) IPv6 was originally designed to not have DHCP, but in practice we still need DHCP (DHCPv6) in most cases. There were a bunch of schemes to try to bootstrap ipv6 adoption and they all made it worse. Way back in the 2000s my cable company had some 6to4 servers that worked. Then later there was "teredo" tunneling included in windows vista I think. And there were more. They're all pretty much forgotten now. The problem was that they gave some percent of consumer computers (maybe 2%? maybe 5%?) a false impression of working ipv6, and these computers would hang when trying to access websites that advertised ipv6 addresses in dns responses. So, many websites that had ipv6 at one point, removed it, for many years, until late 2010s ("ipv6 day" etc). This was fixed with the "happy eyeballs" algorithm and other tricks like not returning ipv6 addresses from dns requests made over ipv4 (not sure how widely this was done, but it was done by some significant number of ISPs). Anyway this set back adoption by 10 years probably. There was even a problem where linux had a sysctl option to automatically listen on a "mapped" ipv6 address whenever a process listened on an ipv4 address, this was automatically enabled on some popular linux distros. Later, when the process tried to explicitly listen on a port on ipv6, it would fail because something was already listening on that port on the wildcard address. So companies had to figure out this issue and disable that sysctl option - but, again, the typical response was "screw it just disable ipv6 everywhere". I'm typing this from a corporate laptop with ipv6 explicitly disabled even though my current network supports it, because the required corporate VPN doesn't support ipv6. Today.
- RamRodification 3y ago
  > "screw it just disable ipv6 everywhere" Troubleshooting step #1. Sad (reasonable, but sad).
justcool393 3y ago
not the original poster but i want to chime in, the address is just poor. an IPv4 address is decent to remember and while DNS is useful, the issue sometimes is DNS, in which case you need the IP anyway. 12:141:::2315:14 or whatever is ugly and terrible syntax. firstly... 1. why colons? if you're typing in an IP address, you might also have to type in a TCP/IP port in colon format, why did IETF think overloading this was a good idea? it also makes the address scheme look ugly. the ways of getting around this by using brackets just look plain awful. 2. why do it in hexadecimal format? there are now 16 characters in each IP digit. i'd rather have (if we really need 128-bit addresses, which since we give out /64s, seems not to be the case) it be in dotted decimal. maybe even make the dotted decimals 16 bits if it's really an issue. do get rid of the myraid of other stupid ways to write IPs though, dotted decimal could easily be standardized. 3. DHCP is a good thing, why is it maligned? a central source of truth who is what is great, at the network level I can say "hey this person has the IP of X." it seems like a much better idea than SLAAC ever was.
- p1mrx 3y ago
  IPv4 allocated prefixes on 8-bit boundaries, so dotted decimal made sense at the time. CIDR in 1993 made the prefix boundaries arbitrary, which required "difficult" math to convert between binary and decimal. So the point of hexadecimal is to make CIDR easier. Consider the sequence of 1s followed by 0s: dec: 0 128 192 224 240 248 252 254 255 hex: 00 80 C0 E0 F0 F8 FC FE FF Once you've adopted hex, dots become a problem: is "1.1.1.1.1.1.beef.de" a domain name or an IP address? Perhaps they could've chosen something other than :, but I'm not sure what. Maybe require every IPv6 address to contain .. somewhere? I don't really have strong opinions on DHCP vs SLAAC.
- justsomehnguy 3y ago
  > an IPv4 address is decent to remember and while DNS is useful, the issue sometimes is DNS, in which case you need the IP anyway It's like rambling about absence of crank handle on modern cars. > why colons Because dots are in the DNS. > why do it in hexadecimal format Because it's shorter than decimal and you can't nest decimal representation without some delimiter, eg 1220 -- is this 12 20 or 122 0 ? Cue in 'but why colons' > DHCP is a good thing, why is it maligned? a central source of truth who is what is great No, it's not. And definitely it's not source of truth. A client can ask, DHCP server can provide an address but if you don't have an address in DHCP leases that means nothing. And even if you have that doesn't mean that this is still the same device.
tsimionescu 3y ago
Isn't NAT the only real difference? In IPv6 you get NDP instead of ARP, but you generally still need DHCPv6 for many kinds of networks. So you have IPv4 + ARP + DHCP + NAT, vs IPv6 + NDP + DHCPv6. Not that much of a difference. Especially since, for a household user, there is actually pretty little difference between NAT and just a stateful firewall.
- enrico204 3y ago
  Actually, if the router supports RDNSS (DNS info in RA), SLAAC is sufficient for household users -- no need for DHCPv6.
  - whatwhaaaaat 3y ago
    Sure for an intranet. Know of any ISPs handing out addresses in slacc? I sure hope not as the rfc (too lazy to find who CV) stipulates resi users should get bigger than a /64. So now we have two types of network addressing depending on which type of network! So simple. All of this is ignoring the absolute madman icmpv6 vulns discovered over the last few years that are generally allowed through do to ndp using icmp. V6 sucks and this is coming from someone who lived and breathed it for years. I do not run it on my sensitive installations.
    - simoncion 3y ago
      > > > Not that much of a difference. Especially since, for a household user, there is actually pretty little difference between NAT and just a stateful firewall. > > Actually, if the router supports RDNSS (DNS info in RA), SLAAC is sufficient for household users -- no need for DHCPv6. > Sure for an intranet. Know of any ISPs handing out addresses in slacc? It's a bit odd to reply to two folks talking about residential LANs with "Yeah, well, what about what ISPs do, eh?!". Reading through the relevant RFCs leaves me pretty sure that SLAAC works for prefixes larger than /64... you just won't get split that into subnets that your router delegates to the LAN side of things.
      - 3y ago

Curious why you think that? IPv4 + ARP + DHCP + NAT has a lot more baggage. IPv6 and a stateful firewall gets the job done quite well, without the address exhaustion.

axytol 3y ago

Not OP and certainly not in the anti-IPv6 camp. I'm wondering though: could you build a case that under IPv4, a misconfigured NAT would only result in lost connectivity for nodes behind the router, while for IPv6 a misconfigured firewall and worse triggered through a vulnerability, would then result in protected nodes being exposed? I know NAT-PMP (port mapping) vulnerabilities exist, allowing external actors to set port mappings to hosts behind NAT, but this seems a bit harder to exploit than a bypassed firewall.

ianlevesque 3y ago
I don't think that's true in general because each of these end-user routers have their own sharp edges. IPv4 consumer routers have a DMZ option which would, for at least 1 device, be the same as taking down your stateful firewall. Also, thankfully, in all of the examples I've seen in the wild, the stateful firewall was just on by default, much as NAT is on by default. In both cases you are taking steps to compromise your own security, that most people won't bother to do. Finally, the risk to an individual machine 'loose on the internet' is lower than its ever been because Windows has for years enabled a firewall by default on its own, and macOS doesn't expose any open ports by default either. That does leave printers, IoT devices, and the like, but now we're really pretty far into the weeds of lots of non-default customization combined with individual CVEs in non-computing hardware.
- iso1631 3y ago
  If my firewall failed then the packet won't reach my 192.168.0.1 DMZ server as it will likely never be translated from my real 12.34.56.78 IP address (as the translation would be part of that stateful firewall) Sure there are exceptions, but you are massively reducing your risk by not having your toaster having a public address by default and having something actively have to translate it to a public address

Quekid5 3y ago

I think it's probably just the fact that the IPv4 stack has just received a lot more hardening because it's deployed everywhere (by necessity)... and IPv4 has had a 15+ years lead over IPv6 on that whole hardening thing because it came later and a time where IPv4 was already pretty well established.

tedunangst 3y ago

How about the fact that half the RFCs you were supposed to implement 20 years ago have been superseded by RFCs saying do not implement?

ianlevesque 3y ago
Not sure why you are being downvoted, if there was a pile of churn in IPv6 recommendations I'm curious about them.
- Macha 3y ago
  * SLAAC with MAC addresses -> Stable privacy addresses * fec0:: site local addresses -> ULAs * No DHCP handing out addresses -> DHCPv6 * "IPv4 compatible" ::<IPv4 address> -> "IPv4 mapped" ::ffff:<IPv4 address> * 6to4 -> Just use dual stack * ip6.int RDNS -> ip6.arpa
  - tedunangst 3y ago
    RH0 was so bad it should count twice.

ploxiln 3y ago

Ah, where to start ... 128-bit addresses are annoyingly huge. 64 bits would have been enough. Even 48 bits gives you 64 thousand times the ipv4 address space. 64 bits gives you 4 billion times the ipv4 address space. In practice the 128-bit address space has been used as wastefully as it allows e.g. giving a whole /64 to a single server (4 billion ipv4 internets to just a single server!) Link-local addresses being automatically assigned to every interface, as they are with ipv6 (fe80::xxxx:xxxx:xxxx:xxxx) means that you need to use an interface index or name to distinguish them, so now addresses sometimes need a "%XX" added on the end, e.g. fe80::1ff:fe23:4567:890a%eth2 (this is specific to the source machine, not dest ...) IPv6 was originally designed to not have DHCP, but in practice we still need DHCP (DHCPv6) in most cases. There were a bunch of schemes to try to bootstrap ipv6 adoption and they all made it worse. Way back in the 2000s my cable company had some 6to4 servers that worked. Then later there was "teredo" tunneling included in windows vista I think. And there were more. They're all pretty much forgotten now. The problem was that they gave some percent of consumer computers (maybe 2%? maybe 5%?) a false impression of working ipv6, and these computers would hang when trying to access websites that advertised ipv6 addresses in dns responses. So, many websites that had ipv6 at one point, removed it, for many years, until late 2010s ("ipv6 day" etc). This was fixed with the "happy eyeballs" algorithm and other tricks like not returning ipv6 addresses from dns requests made over ipv4 (not sure how widely this was done, but it was done by some significant number of ISPs). Anyway this set back adoption by 10 years probably. There was even a problem where linux had a sysctl option to automatically listen on a "mapped" ipv6 address whenever a process listened on an ipv4 address, this was automatically enabled on some popular linux distros. Later, when the process tried to explicitly listen on a port on ipv6, it would fail because something was already listening on that port on the wildcard address. So companies had to figure out this issue and disable that sysctl option - but, again, the typical response was "screw it just disable ipv6 everywhere". I'm typing this from a corporate laptop with ipv6 explicitly disabled even though my current network supports it, because the required corporate VPN doesn't support ipv6. Today.

RamRodification 3y ago
> "screw it just disable ipv6 everywhere" Troubleshooting step #1. Sad (reasonable, but sad).

justcool393 3y ago

not the original poster but i want to chime in, the address is just poor. an IPv4 address is decent to remember and while DNS is useful, the issue sometimes is DNS, in which case you need the IP anyway. 12:141:::2315:14 or whatever is ugly and terrible syntax. firstly... 1. why colons? if you're typing in an IP address, you might also have to type in a TCP/IP port in colon format, why did IETF think overloading this was a good idea? it also makes the address scheme look ugly. the ways of getting around this by using brackets just look plain awful. 2. why do it in hexadecimal format? there are now 16 characters in each IP digit. i'd rather have (if we really need 128-bit addresses, which since we give out /64s, seems not to be the case) it be in dotted decimal. maybe even make the dotted decimals 16 bits if it's really an issue. do get rid of the myraid of other stupid ways to write IPs though, dotted decimal could easily be standardized. 3. DHCP is a good thing, why is it maligned? a central source of truth who is what is great, at the network level I can say "hey this person has the IP of X." it seems like a much better idea than SLAAC ever was.

p1mrx 3y ago
IPv4 allocated prefixes on 8-bit boundaries, so dotted decimal made sense at the time. CIDR in 1993 made the prefix boundaries arbitrary, which required "difficult" math to convert between binary and decimal. So the point of hexadecimal is to make CIDR easier. Consider the sequence of 1s followed by 0s: dec: 0 128 192 224 240 248 252 254 255 hex: 00 80 C0 E0 F0 F8 FC FE FF Once you've adopted hex, dots become a problem: is "1.1.1.1.1.1.beef.de" a domain name or an IP address? Perhaps they could've chosen something other than :, but I'm not sure what. Maybe require every IPv6 address to contain .. somewhere? I don't really have strong opinions on DHCP vs SLAAC.
justsomehnguy 3y ago
> an IPv4 address is decent to remember and while DNS is useful, the issue sometimes is DNS, in which case you need the IP anyway It's like rambling about absence of crank handle on modern cars. > why colons Because dots are in the DNS. > why do it in hexadecimal format Because it's shorter than decimal and you can't nest decimal representation without some delimiter, eg 1220 -- is this 12 20 or 122 0 ? Cue in 'but why colons' > DHCP is a good thing, why is it maligned? a central source of truth who is what is great No, it's not. And definitely it's not source of truth. A client can ask, DHCP server can provide an address but if you don't have an address in DHCP leases that means nothing. And even if you have that doesn't mean that this is still the same device.

tsimionescu 3y ago

Isn't NAT the only real difference? In IPv6 you get NDP instead of ARP, but you generally still need DHCPv6 for many kinds of networks. So you have IPv4 + ARP + DHCP + NAT, vs IPv6 + NDP + DHCPv6. Not that much of a difference. Especially since, for a household user, there is actually pretty little difference between NAT and just a stateful firewall.

enrico204 3y ago
Actually, if the router supports RDNSS (DNS info in RA), SLAAC is sufficient for household users -- no need for DHCPv6.
- whatwhaaaaat 3y ago
  Sure for an intranet. Know of any ISPs handing out addresses in slacc? I sure hope not as the rfc (too lazy to find who CV) stipulates resi users should get bigger than a /64. So now we have two types of network addressing depending on which type of network! So simple. All of this is ignoring the absolute madman icmpv6 vulns discovered over the last few years that are generally allowed through do to ndp using icmp. V6 sucks and this is coming from someone who lived and breathed it for years. I do not run it on my sensitive installations.
  - simoncion 3y ago
    > > > Not that much of a difference. Especially since, for a household user, there is actually pretty little difference between NAT and just a stateful firewall. > > Actually, if the router supports RDNSS (DNS info in RA), SLAAC is sufficient for household users -- no need for DHCPv6. > Sure for an intranet. Know of any ISPs handing out addresses in slacc? It's a bit odd to reply to two folks talking about residential LANs with "Yeah, well, what about what ISPs do, eh?!". Reading through the relevant RFCs leaves me pretty sure that SLAAC works for prefixes larger than /64... you just won't get split that into subnets that your router delegates to the LAN side of things.
    - 3y ago