Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 791: Internet Protocol (1981)

datatracker.ietf.org

Post reply on HN
Print view View original

11–20 of 45 posts

Re: RFC 791: Internet Protocol (1981)

#11

Post by adrian_b »

hansel_der wrote: post #7
corty wrote: post #6

Earlier quoted context omitted.

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 t…

I do not know what you mean by "multiple classes of numbers".

A firewall must block everything by default.

You add then exceptions for the protocols, hosts and ports that you want to allow.

Regardless whether you use IPv4 or IPV6, you have the same number of protocols, hosts and ports for which you must add rules.

The only disadvantage of IPv6 is that you should be more careful when you copy and paste the host addresses into rules, because the IPv6 addresses are longer and it might be more difficult to notice typing errors in them.

On the other hand, you no longer need to add NAT rules.

Re: RFC 791: Internet Protocol (1981)

#12

Post by trulyrandom »

formerly_proven wrote: post #9
jl6 wrote: post #3

Earlier quoted context omitted.

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 p…

I'm not a network guy, so forgive my ignorance, but this is the first time I'm hearing about this. Why will IPv6 cause inexplicable hangs and timeouts?

Re: RFC 791: Internet Protocol (1981)

#13

Post by znpy »

rnhmjoj wrote: post #8
znpy wrote: post #4

Earlier 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…

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 connectio…

Congratulations, you missed the point

The ISP level yada yada doesn't matter, nobody cares about that at a consumer level.

NAT doesn't imply firewalling, that true, but NAT also means that hosts being the gateway are not exposed by default.

Re: RFC 791: Internet Protocol (1981)

#14

Post by adrian_b »

znpy wrote: post #13
rnhmjoj wrote: post #8

Earlier quoted context omitted.

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 connectio…

Congratulations, you missed the point The ISP level yada yada doesn't matter, nobody cares about that at a consumer level. NAT doesn't imply firewalling, that true, but NAT also means that hosts being the gateway are not exposed by default.

Exposing by default or not does not have anything to do with NAT.

It only depends on the default firewall rules.

The default rules should not allow connections from outside, regardless whether NAT is used or not and regardless whether IPv6 is used or not.

Any device with a network interface connected directly to Internet must have an active firewall.

Re: RFC 791: Internet Protocol (1981)

#15

Post by throw0101a »

formerly_proven wrote: post #9
jl6 wrote: post #3

Earlier quoted context omitted.

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 p…

> The value prop of v6 is: ??? Learn an entirely new networking stack!

The value prop of IPv6 is not having to pay US$ 30/IP (and rising) when you need a block of new IPs. Most folks don't need that many public IPs and so simply use RFC 1918 addresses and then implement the kludge that is NAT. NA(P)T was codified in 1999 (RFC 2663), and it is now "background radiation" so people think it's normal because it's all that they've ever know.

But we've long gotten to the point where we're now doing double-(CG)NAT, and entire chunk of address space (100.64.0.0/10) has been reserved just for this purpose:

* https://en.wikipedia.org/wiki/IPv4_shared_address_space

I'm waiting for triple-NATing to start occurring.

Re: RFC 791: Internet Protocol (1981)

#16

Post by adrian_b »

adrian_b wrote: post #14
znpy wrote: post #13

Earlier quoted context omitted.

Congratulations, you missed the point The ISP level yada yada doesn't matter, nobody cares about that at a consumer level. NAT doesn't imply firewalling, that true, but NAT also means that hosts being the gateway are not exposed by default.

Exposing by default or not does not have anything to do with NAT. It only depends on the default firewall rules. The default rules should not allow connections from outside, regardless whether NAT is used or not and regardless whether IPv6 is used or not. Any device with a network interface connected directly to Internet must have an active firewall.

Whoever downvoted this does not know how NAT and firewalls function.

That NAT and firewall are independent functions, even if they may be performed by the same program, is a simple true fact, which cannot be contested.

NAT cannot enhance security in any way. On the contrary, only the absence of any NAT can enhance the security of private IPv4 networks, because only when NAT does not exist, the computers with private addresses are no longer reachable from outside. Whenever a device that does NAT exists in your network, your internal private addresses become public addresses, no longer hidden from the Internet, because that is what NAT does. The fact that multiple internal addresses are mapped to a single external address may make more difficult the tracking of individual users, but it does not protect the internal computers in any way from external accesses. That is the job of the firewall, which filters the undesirable IP packets.

So anyone who believes that NAT is something that provides security is delusional.

I own a subnetwork of public IPv4 addresses and I have a private network of computers connected to the Internet through a router/firewall, which is a standard PC on which I have been managing the firewall and NAT for almost 20 years.

Neither of my 2 ISP's supports IPv6, so I use IPv4 with NAT.

However, if I could use IPv6, rewriting the firewall rules would not take more than a few minutes and the security would be exactly the same as it is with IPv4 and NAT.

Re: RFC 791: Internet Protocol (1981)

#17

Post by throw0101a »

znpy wrote: post #4
diea wrote: post #2

And 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…

> 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)

IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4.

An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table/s it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.

The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.

With IPv6 address/port, rewriting is not done. Only state tables are updated and checked.

New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.

There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.

The security comes from the state checking.

> […] and it was happily listening on the public internet for something to print.

I have a printer with an IPv6 stack. I also have IPv6 addresses from my ISP. Yet somehow my Asus AC-68U prevents the public Internet from reaching my printer…

Re: RFC 791: Internet Protocol (1981)

#18

Post by corty »

trulyrandom wrote: post #12
formerly_proven wrote: post #9

Earlier quoted context omitted.

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 p…

I'm not a network guy, so forgive my ignorance, but this is the first time I'm hearing about this. Why will IPv6 cause inexplicable hangs and timeouts?

When a server has IPv4 and IPv6 connectivity, i.e. an A and AAAA DNS record, clients would usually try IPv6 first, then IPv4. Now, if IPv6 is broken somehow (as it was prone to be due to tunneling, Teredo and even nowadays stupid ISPs), the client would wait for a connection timeout, then try IPv4, so every connection would hang for one timeout.

Nowadays, most clients, especially browsers, will try IPv4 and IPv6 concurrently and use the connection that comes back with an ack first. This prevents hangs at the expense of a little higher server resource usage.

But the myth of "IPv6 makes things hang randomly" remains.

Re: RFC 791: Internet Protocol (1981)

#19

Post by formerly_proven »

corty wrote: post #18
trulyrandom wrote: post #12

Earlier quoted context omitted.

I'm not a network guy, so forgive my ignorance, but this is the first time I'm hearing about this. Why will IPv6 cause inexplicable hangs and timeouts?

When a server has IPv4 and IPv6 connectivity, i.e. an A and AAAA DNS record, clients would usually try IPv6 first, then IPv4. Now, if IPv6 is broken somehow (as it was prone to be due to tunneling, Teredo and even nowadays stupid ISPs), the client would wait for a connection timeout, then try IPv4, so every connection would hang for one timeout. Nowadays, most clients, especially browsers, will try IPv4 and IPv6 conc…

It's not a myth when it happens. Last time I tried v6 again on my network (about a year ago) I had these issues. Not a lot of them, but toggling v6 off made them go away. There are fewer issues, true, but having dual-stack does still appear to break some things. I say "appear to" because I'm assuming that it's not actually an issue with v4+v6 dual stack, but rather a problem with misconfigured services (e.g. services having wrong AAAA records, stuff using v6 that doesn't work properly with v6 etc.); from an end-user perspective this does not really matter: There are sometimes issues when v6 is on, which go away by turning v6 off - end user perception: v6 is wonky.

Re: RFC 791: Internet Protocol (1981)

#20

Post by MisterTea »

formerly_proven wrote: post #9
jl6 wrote: post #3

Earlier quoted context omitted.

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 p…

I believe XP64 was OEM only, there was no retail availability. I had.. uh ... obtained a copy and installed it on my brothers gaming PC and it ran surprisingly well for an OS that barely made it to market.
Post reply on HN