RFC 791: Internet Protocol (1981)
datatracker.ietf.org
RFC 791: Internet Protocol (1981)
1–10 of 45 posts
Re: RFC 791: Internet Protocol (1981)
#2And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
Re: RFC 791: Internet Protocol (1981)
#3And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
Compare IPv6 adoption to that other generational migration of our time: 32-bit x86 to 64-bit x86. The first x86-64 CPUs became available in 1999, while 32-bit Windows will still be supported through to 2025 on Windows 10. Only with Windows 11 will the world’s mainstream OS finally complete the move away from 32-bit.
IPv6 migration is much more complex, so I don’t think we’re doing too badly, and I think we’ll be done around 2040.
Re: RFC 791: Internet Protocol (1981)
#4And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
Not sure about operating system readiness besides the presence of an ipv6 stack though.
Can you imagine most consumer pc, barely updated, being publicly exposed?
Can you imagine the average senile pc user having to deal with a firewall? firewall exceptions?
NGL I have ipv6 at home but made sure it's disabled at my parents' home. It's just a recipe for disasters.
I'm well aware that ipv4+nat is not "security"... yet it removes a whole class of problem (eg: windows print spooler is listening on [::] by default or something like that)
EDIT: and some appliances too. I had to check twice last time I got a network enabled printer... It has an ipv6 stack, I had ipv6 enabled at home, and it had got a public ipv6 (besides the ULA address and the link-local address) and it was happily listening on the public internet for something to print.
I have looked at some consumer internet routers and there's still not enough ipv6 firewalling at router/gateway level (which become a necessity when NAT is lifted)
Re: RFC 791: Internet Protocol (1981)
#5And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
Not sure about operating system readiness besides the presence of an ipv6 stack though. Can you imagine most consumer pc, barely updated, being publicly exposed? Can you imagine the average senile pc user having to deal with a firewall? firewall exceptions? NGL I have ipv6 at home but made sure it's disabled at my parents' home. It's just a recipe for disasters. I'm well aware that ipv4+nat is not "security"... yet i…
Adding the right rules for a firewall is not more difficult for IPv6 than for IPv4 with NAT, if anything it is simpler.
It is true that usually NAT is configured by default to not accept connections from outside to inside, but any firewall should have default rules that forbid such connections for any protocol, both for IPv4 and for IPv6.
Nonetheless, you are probably right that many, maybe most, home routers/firewalls might come with bad default configurations, where instead of having sane default rules for IPv6, there might be just a default rule to pass all.
If that is the case, it is not the fault of IPv6 but of the device manufacturers. For NAT it is also possible to put stupid default firewall rules, that just is less common, because almost all customers use NAT and the bad defaults are frequently noticed and reported.
Re: RFC 791: Internet Protocol (1981)
#6Earlier quoted context omitted.
Not sure about operating system readiness besides the presence of an ipv6 stack though. Can you imagine most consumer pc, barely updated, being publicly exposed? Can you imagine the average senile pc user having to deal with a firewall? firewall exceptions? NGL I have ipv6 at home but made sure it's disabled at my parents' home. It's just a recipe for disasters. I'm well aware that ipv4+nat is not "security"... yet i…
Adding the right rules for a firewall is not more difficult for IPv6 than for IPv4 with NAT, if anything it is simpler. It is true that usually NAT is configured by default to not accept connections from outside to inside, but any firewall should have default rules that forbid such connections for any protocol, both for IPv4 and for IPv6. Nonetheless, you are probably right that many, maybe most, home routers/firewal…
Most consumer NATs are intentionally configured to be leaky. A commonly used technique is hole punching (https://en.wikipedia.org/wiki/Hole_punching_(networking) ), which all consumer NATs are prone to support because otherwise many popular applications such as games, voice- and videoconferencing won't work. There are also formally specified protocols to expose hosts to connections from outside: https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc... https://en.wikipedia.org/wiki/Port_Control_Protocol and others. All this is done with no or poor authentication, so any malware that managed to make it inside your network (e.g. by a guest carrying an infected device) can just request your home router to open ports. There have even been problems where such protocols were open to the outside internet, of course without auth. There have been problems with misdirected exposed ports when hosts go offline and addresses are reassigned. Those just don't make headline news because the protocols work as intended and each misconfiguration is unique, automatic and temporary.
So, first, your IPv4 NAT has crappy security already, by virtue of needing to accomodate services like realtime audio/video/control that won't work properly without incoming connections. Second, IPv6 is supported in the same way, PCP can just do the same for IPv6 firewall rules as it does for IPv4 NAT exposed ports.
There is absolutely no reason to not use IPv4 over IPv6, it'll work the same from an end-user's view. But it'll be slightly less messy because you just configure firewall rules per IPv6 address instead of translating the limited port space of your one external IPv4 address into a number of internal Port/IPv4 combinations. So the chance to screw up is lessened.
Re: RFC 791: Internet Protocol (1981)
#7Earlier quoted context omitted.
Adding the right rules for a firewall is not more difficult for IPv6 than for IPv4 with NAT, if anything it is simpler. It is true that usually NAT is configured by default to not accept connections from outside to inside, but any firewall should have default rules that forbid such connections for any protocol, both for IPv4 and for IPv6. Nonetheless, you are probably right that many, maybe most, home routers/firewal…
Most consumer NATs are intentionally configured to be leaky. A commonly used technique is hole punching ( https://en.wikipedia.org/wiki/Hole_punching_(networking) ), which all consumer NATs are prone to support because otherwise many popular applications such as games, voice- and videoconferencing won't work. There are also formally specified protocols to expose hosts to connections from outside: https://en.wikipedia…
> it'll be slightly less messy because you just configure firewall rules per IPv6 address instead of translating the limited port space of your one external IPv4 address into a number of internal Port/IPv4 combinations. So the chance to screw up is lessened.
as mentioned, with ipv6 you now have to care/worry about multiple classes of numbers, so i'd argue that because the number-space is increased, so is the chance to screw up.
i grew up with windows 3.x computers having a public ip and no firewall and as nice as incoming connections by default are for an enthusiast, they are a unecessary danger for the masses.
as you said, hole-punching works on ipv6 as well and has to be initiated from the inside, so it's no argument for .
Re: RFC 791: Internet Protocol (1981)
#8And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
Not sure about operating system readiness besides the presence of an ipv6 stack though. Can you imagine most consumer pc, barely updated, being publicly exposed? Can you imagine the average senile pc user having to deal with a firewall? firewall exceptions? NGL I have ipv6 at home but made sure it's disabled at my parents' home. It's just a recipe for disasters. I'm well aware that ipv4+nat is not "security"... yet i…
Ah, the inevitable NAT security comment on every IPv6 discussion.
> yet it removes a whole class of problem (eg: windows print spooler is listening on [::] by default or something like that)
NAT is just address translation, that's it: it doesn't imply a firewall. What you're thinking is a typical CPE router which, along masquerading the usual RFC 1918 range, runs a stateful firewall that blocks all incoming connections by default (but can be easily punched, even automatically by NAT-PMP, UPnP and a bunch of other protocols).
Lifting the NAT doesn't mean lifting the firewall: new ISPs that deployed native IPv6 are doing exactly the same firewalling as before.
Re: RFC 791: Internet Protocol (1981)
#9And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
Compare IPv6 adoption to that other generational migration of our time: 32-bit x86 to 64-bit x86. The first x86-64 CPUs became available in 1999, while 32-bit Windows will still be supported through to 2025 on Windows 10. Only with Windows 11 will the world’s mainstream OS finally complete the move away from 32-bit. IPv6 migration is much more complex, so I don’t think we’re doing too badly, and I think we’ll be done…
AMD64 hit the market in 2003. Adoption on the software, desktop side was mostly delayed because Vista as a whole failed and XP64 was very niche (on servers and Linux desktops everyone jumped on it). 32 bit Windows outside VMs is only really needed for Intels gimped low end SoCs which lacked AMD64 support for a long time.
The value prop of AMD64 was very clear from the start: better performance, more memory, without porting to a 64 bit RISC which coincidentally were all dying or dead at the time. The only other option at the time was IA64 - Itanium - which sucked and was way more expensive.
The value prop of v6 is: ??? Learn an entirely new networking stack! Enjoy degraded service because v6 will cause inexplicable hangs and timeouts! Deal with a weird ass protocol founded on perimeter security which is not something we have been doing for 20 years! Fun for the whole family!
Re: RFC 791: Internet Protocol (1981)
#10And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
I suspect that one of the reasons why ipv6 is being held back is because of people who hoard IPv4 addresses have an interest to gatekeep them so that they can rent them to you.
Not to mention speculation https://news.ycombinator.com/item?id=19923519