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

21–30 of 45 posts

Re: RFC 791: Internet Protocol (1981)

#21

Post by rnhmjoj »

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.

I haven't mentioned the ISP level networking anywhere. The router provided by an ISP with native IPv6 to you (or any consumer router you can buy, for that matter) is using the exact same firewall with the same rules: they just don't do NAT because it's not needed anymore.

By this I mean that new WAN to LAN connections are blocked by default, LAN to WAN connections are allowed by default, ICMP is allowed etc. The only difference is that in IPv4 to "open a port" you have to:

1. map a LAN port/address to a WAN port using a DNAT destination rule

2. write a firewall rule to allow WAN traffic through that port

while in IPv6 you just do 2. Same result, same level of security, just less steps. These two steps are usually bundled into one operation in your familiar home router web UI, and this is why many confuse NAT with a firewall/some kind of security feature.

Re: RFC 791: Internet Protocol (1981)

#22

Post by tenebrisalietum »

throw0101a wrote: post #15
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…

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

NAT is essentially required in IPv4 due to IPv4 address exhaustion.

NAT, when done on the carrier level (CGNAT), more or less prevents external systems from initating connections with anything on your network (without ISP involvement). You can still initiate outgoing connections fine.

Sounds great for security, but this enforces the existence of centralized services (middlemen) that you have to use/pay for if you want to have asynchronous communication with anyone that you might not necessarily initiate.

If you want a chance at a real decentralized Internet without dependency on tech giants, you're gonna need IPv6.

Re: RFC 791: Internet Protocol (1981)

#23

Post by fanf2 »

throw0101a wrote: post #15
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…

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

It’s easy to cause triple-NAT if you tether to a phone, or if you run VMs at home...

One of the vexing things about IPv4 (which is not really fixed by IPv6) is that endpoint devices are connected to the network but not really part of the network: there are different sets of protocols for connectivity within the network, and at the edge of the network. So an edge device (your phone, your VM host) can’t easily extend the network to more downstream systems (tethered devices, VMs) without hacks that hide the cluster from the network so the whole thing still appears to be a single device.

Re: RFC 791: Internet Protocol (1981)

#25

Post by formerly_proven »

MisterTea wrote: post #20
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 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.

XP x64 was available in retail, I used it for a pretty long time. The biggest issue was lack of drivers for stuff like printers and scanners, though iirc later on the Vista 64-bit drivers would usually work.

Re: RFC 791: Internet Protocol (1981)

#26

Post by formerly_proven »

fanf2 wrote: post #23
throw0101a wrote: post #15

Earlier quoted context omitted.

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

It’s easy to cause triple-NAT if you tether to a phone, or if you run VMs at home... One of the vexing things about IPv4 (which is not really fixed by IPv6) is that endpoint devices are connected to the network but not really part of the network: there are different sets of protocols for connectivity within the network, and at the edge of the network. So an edge device (your phone, your VM host) can’t easily extend t…

Right. This is a big clash between the "v4 model" (as it has panned out in practice) and the "v6 model". The OG assumption of both was that there is _only one_ Network, but v4 in practice turned out to be segregated, private networks that happen to have a gateway to The Network. The original RFCs for private IPv4 networks and NAT explicitly call this change in stance out. So v6 was designed to go back to a world with only The One Network. The possibility of having a private v6 network was added much later (some time in the 2000s I think?).

This is probably why going to v6 is so confusing even for us Elite HN Readers; you don't have a private network connected to The Internet any more, The Internet directly extends to all devices. You can have a private network _in addition_ to that though.

This is actually pretty nice because it restores end-to-end connectivity, so P2P and mesh networking become easier; however, most everyone has a central firewall between their splinter of The Internet and The Greater Internet, so in practice you still need hole punching and some central services to offer hole punching duties, because hole punching works around NAT and opens a port in stateful firewalls; v6 only removes the NAT part in most instances. So in reality P2P with v6 is only slightly less messy than with v4.

Re: RFC 791: Internet Protocol (1981)

#27

Post by throwaway525142 »

adrian_b wrote: post #16
adrian_b wrote: post #14

Earlier quoted context omitted.

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…

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

If I understand NATs correctly, they cannot route incoming connections (from the Internet) to a computer on the local network because they don't know which computer to route them to. Hence incoming connections will always fail (unless configured to go to a specific computer, "port forwarding"). Thus a NAT (by design, because it cannot operate in another fashion), blocks incoming connections. I'd think this is a security benefit (over having a public IP address for every device in the network like in IPv6, but without a firewall).

Care to elaborate why my example doesn't work/misses your point?

Re: RFC 791: Internet Protocol (1981)

#28

Post by p1mrx »

fanf2 wrote: post #23
throw0101a wrote: post #15

Earlier quoted context omitted.

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

It’s easy to cause triple-NAT if you tether to a phone, or if you run VMs at home... One of the vexing things about IPv4 (which is not really fixed by IPv6) is that endpoint devices are connected to the network but not really part of the network: there are different sets of protocols for connectivity within the network, and at the edge of the network. So an edge device (your phone, your VM host) can’t easily extend t…

The "single device" problem comes from WiFi, not IP. Normally, you can extend Ethernet by plugging in a switch or bridge, but WiFi is limited to 1 MAC address per associated client, unless operating in WDS mode.

So an unprivileged WiFi client needs to hide tethered devices and VMs behind a single MAC address, using ARP proxy (IPv4) or ND proxy (IPv6). These proxies do NAT-like mangling of MAC addresses, but are mostly transparent at the IP layer.

The Linux environment on Chrome OS uses ND proxy, and IPv6 works fine on WiFi. Compare that to WSL2 on Windows, which is IPv4-only.

Re: RFC 791: Internet Protocol (1981)

#29

Post by [deleted] »

minroot wrote: post #24

PDFs provided by datatracker.ietf.org don't have hyperlinks. html rfc URLs on tools.ietf.org (which had links to PDF) now redirects to datatracker.ietf.org PDFs from tools.ietf.org are still available on their previous URLs. like for rfc791 it is https://tools.ietf.org/pdf/rfc791.pdf

[deleted]

Re: RFC 791: Internet Protocol (1981)

#30

Post by adrian_b »

throwaway525142 wrote: post #27
adrian_b wrote: post #16

Earlier quoted context omitted.

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…

> So anyone who believes that NAT is something that provides security is delusional. If I understand NATs correctly, they cannot route incoming connections (from the Internet) to a computer on the local network because they don't know which computer to route them to. Hence incoming connections will always fail (unless configured to go to a specific computer, "port forwarding"). Thus a NAT (by design, because it canno…

It is true that for incoming connections you normally have to include in the NAT configuration the local IPv4 address to which the connection requests should be sent.

Otherwise the NAT would have to guess if they should be sent to one of the local addresses already seen to be in use.

In any case there is no difference between what happens when you use NAT and what happens when you have only public addresses in your internal network, either IPv6 or IPv4, it does not matter.

If you have internal public addresses, the incoming connections cannot reach them anyway, until you add a firewall rule allowing a connection with a certain protocol for a certain port and internal host, which is done exactly like when adding the same rule in the NAT case.

If the NAT does not allow incoming connections without express configuration, then it has correct default firewall filtering rules.

The fact that there may be multiple internal computers, is not something that would block the connection, because the NAT can choose the first of the internal addresses that it has seen, maybe rotating the addresses for the next connection requests.

So what blocks the incoming connections is the lack of permission to do that, not the fact that the NAT could not do that if allowed.

It would not surprise me if there are some NAT implementations that attempt to be too helpful so they might send the incoming connections to your local computer even without any configuration for this.

Post reply on HN