Live data from Hacker News

So Long Last /8 and Thanks For All the Allocations

labs.ripe.net

191–200 of 201 posts

Re: So Long Last /8 and Thanks For All the Allocations

#191
post #27

Is it time to just admit IPv6 is a failure and move on to new standard? Adoption is very slow though economical needs are already here. Instead of complaining about users maybe we should do something so they actually want to switch?

IPv4 worked for a long time and works for majority of installations now. It's hard to migrate when advantages are not obvious. I'm not sure that IPv6 is very good, I'm always having problem with it, but any standard will have adoption problems when current solution is good enough. I don't think that there's need for new standard and I'm sure that new standard won't be adopted better than IPv6.

I'm not sure that IPv4 is very good, I'm always having issues with NAT etc

Re: So Long Last /8 and Thanks For All the Allocations

#192
post #152

Earlier quoted context omitted.

How come IPv6 wasn't standardized before 2017? I suspect there's some kind of story there. Do you happen to know the details? Any links/pointers? Thanks!

It's just nonsense. In the IETF's nomenclature, the label "Internet Standard" is used to refer to, and I quote: A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held be…

I'm sort of familiar with how sacred these standards are. I'm interested in what was the deciding factor, when IETF and which WG decided now we have enough (significant) successful operational experience.

It's surprising, because IPv6 was set in stone at least around 2010 already, with a lot of experience (6bone ended in 2006, and so on), but on the hand general rollout is still very much ongoing.

Re: So Long Last /8 and Thanks For All the Allocations

#193
post #150

Earlier quoted context omitted.

Care to share them? And how is NAT not added security by default? By default it drops everything incoming, no? (I mean, theoretically NAT doesn't, but [almost] every practical implementation situations means that there's no possible automatic internal-external address correspondence, otherwise you wouldn't need the NAT.)

A NAT doesn't drop anything. A NAT translates. A firewall drops. If you only have a NAT, your ISP (or anyone who has compromised their router, or possibly simply your neighbour when ISPs occasionally fail to isolate their customers on layer 2) still can send you packets addressed directly to your "internal" addresses. The only thing that actually helps is a stateful firewall. And when you have that, the NAT does not…

By default a NAT is unconfigured, so it doesn't know what to translate into what. The usual practical deployment consists of a dynamic outgoing NAT setup and UPnP. So outgoing TCP/UDP/etc protocols are snooped and the incoming packets are translated accordingly. (Hence the UDP NAT hole punching technique.) This setup works well for SoHo sites.

In this case without knowing my egress traffic, any incoming packet will be dropped by the NAT middlebox/facility/software/device/module/thing. So NATs do drop. And nice ones emit ICMP or TCP RST too.

> The only thing that actually helps is a stateful firewall. And when you have that, the NAT does not add anything security-wise.

Yes, indeed. That's a different threat model though. And I agree that hosts should have a default deny ingress policy.

Yet NATs do work wonderfully for SoHo networks. And of course a stateful firewall is just as easy to fool (circumvent) with a back-connecting connection as a NAT.

And a NAT as described above or a stateful firewall that enables local network functions such as CIFS/SMB were just as vulnerable to the usual Blaster-type worms/malware.

Again, of course, usually things go hand in hand. Firewalls usually have SNAT/DNAT capabilities, and SoHo shitboxes come with too much of every kind of NAT/firewall thingies already.

And, I know the misery of interconnecting two internal networks both using the same 192.168.0.0/24 or whatever prefix, so I can't wait to get rid of this and move to proper v6. But the fact of life is that the typical NAT setup was very convenient for ticking the local network ingress security checkbox for ISPs for years (decades).

Re: So Long Last /8 and Thanks For All the Allocations

#194
post #193

Earlier quoted context omitted.

A NAT doesn't drop anything. A NAT translates. A firewall drops. If you only have a NAT, your ISP (or anyone who has compromised their router, or possibly simply your neighbour when ISPs occasionally fail to isolate their customers on layer 2) still can send you packets addressed directly to your "internal" addresses. The only thing that actually helps is a stateful firewall. And when you have that, the NAT does not…

By default a NAT is unconfigured, so it doesn't know what to translate into what. The usual practical deployment consists of a dynamic outgoing NAT setup and UPnP. So outgoing TCP/UDP/etc protocols are snooped and the incoming packets are translated accordingly. (Hence the UDP NAT hole punching technique.) This setup works well for SoHo sites. In this case without knowing my egress traffic, any incoming packet will b…

> In this case without knowing my egress traffic, any incoming packet will be dropped by the NAT middlebox/facility/software/device/module/thing. So NATs do drop.

No, that is the firewall, or simply the IP stack of the device, not the NAT. A NAT only translates. In your typical home setup, it will track connections coming from the LAN side and translate the source address of the connection to the public address, and then match packets of the same connection in the opposite direction and translate them back. If there is a packet coming in on the WAN side that does not match any known connections that are being translated, the packet is simply left unmodified by the NAT. If it happens to be addressed to the public adress of the gateway, it will then be passed to the higher layers of the IP stack of the gateway where it might be delivered to some TCP or UDP socket or who knows what other stuff that is running on the device and using IP--and if the IP stack cannot find any applicable socket to deliver it to, it might respond with the appropriate ICMP error or TCP reset or whatever. If the packet is not addressed to the gateway's public address, it will simply be forwarded to wherever the routing table says--if it's addressed to an address from the LAN range, it will be forwarded to the LAN.

A NAT without a firewall does not drop packets. A NAT only translates addresses of packets belonging to connections it is configured to translate, everything else is left untouched. If there is no firewall in addition to the NAT, it will not prevent inbound connections from the WAN side to the LAN side.

> But the fact of life is that the typical NAT setup was very convenient for ticking the local network ingress security checkbox for ISPs for years (decades).

Well, the real fact of life is that tons of supposed network professionals think that, and then potentially deploy a pure NAT setup that allows unlimited access to the LAN from the ISP's router and possibly other customers of the ISP when the ISP fails to properly isolate customers on layer 2 because of the completely baseless assumption that a NAT prevents inbound connections.

Re: So Long Last /8 and Thanks For All the Allocations

#195

Earlier quoted context omitted.

Consider that when Trumpet Winsock was a third-party IP add-on for Windows 3.1, classic MacOS already had IP support built-in. Ironically around that time Microsoft was selling Xenix ( https://en.wikipedia.org/wiki/Xenix ) which did support it.

Originally Apple's MacTCP was actually a product they sold separately, it wasn't bundled into the OS until 1994. Although it was usually easy to get a hold of a copy since universities and such had site licenses, and ISPs often had redistribution licenses

Ah, it was introduced in System 7.5 which, perhaps coincidentally, was the first version of MacOS I had when I needed to connect it over TCP/IP.

Re: So Long Last /8 and Thanks For All the Allocations

#196

Earlier quoted context omitted.

IPv4 worked for a long time and works for majority of installations now. It's hard to migrate when advantages are not obvious. I'm not sure that IPv6 is very good, I'm always having problem with it, but any standard will have adoption problems when current solution is good enough. I don't think that there's need for new standard and I'm sure that new standard won't be adopted better than IPv6.

I'm not sure that IPv4 is very good, I'm always having issues with NAT etc

What issues? NAT always worked fine for me. It's one iptables rule and one sysctl.

Re: So Long Last /8 and Thanks For All the Allocations

#197
post #150
post #134

Earlier quoted context omitted.

Particularly notable example of this is that the three ip6tables rules needed to get NAT-like everything out nothing out behavior are exactly the same three rules that you need in v4 iptables for the NAT to have any security effect at all.

Care to share them? And how is NAT not added security by default? By default it drops everything incoming, no? (I mean, theoretically NAT doesn't, but [almost] every practical implementation situations means that there's no possible automatic internal-external address correspondence, otherwise you wouldn't need the NAT.)

Sure

    -A FORWARDING -i internal -o external -j ACCEPT
    -A FORWARDING -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWADING -j REJECT
Last one can be done as policy on FORWARDING chain (ie. -P instead of -A), but in this way it is more explicit.

Re: So Long Last /8 and Thanks For All the Allocations

#198

Earlier quoted context omitted.

I'm not sure that IPv4 is very good, I'm always having issues with NAT etc

What issues? NAT always worked fine for me. It's one iptables rule and one sysctl.

NAT breaks the original design of the internet where every endpoint should be reachable from anywhere. Try using protocols that rely on this (like SIP) and see how far you go.

Re: So Long Last /8 and Thanks For All the Allocations

#199
post #193

Earlier quoted context omitted.

By default a NAT is unconfigured, so it doesn't know what to translate into what. The usual practical deployment consists of a dynamic outgoing NAT setup and UPnP. So outgoing TCP/UDP/etc protocols are snooped and the incoming packets are translated accordingly. (Hence the UDP NAT hole punching technique.) This setup works well for SoHo sites. In this case without knowing my egress traffic, any incoming packet will b…

> In this case without knowing my egress traffic, any incoming packet will be dropped by the NAT middlebox/facility/software/device/module/thing. So NATs do drop. No, that is the firewall, or simply the IP stack of the device, not the NAT. A NAT only translates. In your typical home setup, it will track connections coming from the LAN side and translate the source address of the connection to the public address, and…

This is largely theoretical now, as there's a single bit difference in definition (or implementation) of a NAT. (Leaves unknown untouched, or drops them.) But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model.

> deploy a pure NAT setup

Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadget?

Re: So Long Last /8 and Thanks For All the Allocations

#200
post #199

Earlier quoted context omitted.

> In this case without knowing my egress traffic, any incoming packet will be dropped by the NAT middlebox/facility/software/device/module/thing. So NATs do drop. No, that is the firewall, or simply the IP stack of the device, not the NAT. A NAT only translates. In your typical home setup, it will track connections coming from the LAN side and translate the source address of the connection to the public address, and…

This is largely theoretical now, as there's a single bit difference in definition (or implementation) of a NAT. (Leaves unknown untouched, or drops them.) But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model. > deploy a pure NAT setup Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadg…

> This is largely theoretical now, as there's a single bit difference in definition (or implementation) of a NAT. (Leaves unknown untouched, or drops them.)

So ... any distinction between two different things is a single-bit difference and therefore largely theoretical? I am not sure I follow ...

> But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model.

Which is the important point, in particular in this context where the common argument essentially is "because I consider dropping packets a function of a NAT, NAT is good to have", where the whole argument only hinges on the definition, not on any real-world facts about network devices.

> Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadget?

I don't know, I have never investigated that, as I don't tend to use off the shelf network gadgets. However, there is no need to use raw sockets, just install Linux and use the kernel's netfilter, which behaves in exactly that way: If you only configure NAT rules but no filtering rules to prevent inbound connections, your LAN is wide open. And that is not bad design, that is the obvious way to implement this as a matter of separating concerns.

Now, Linux is (was?) a popular OS for off the shelf home routers, and some of them at some point even use(d?) netfilter for their NAT. If you consider what kinds of completely moronic security holes have been and still are being found in those kinds of devices (shell injection in the web interface, trivial buffer overflows, backdoors with hard-coded passwords, ...), that does not make me particularly optimistic that they are careful when putting together the actual network setup on those devices. Not configuring the filtering of inbound connections is exactly the kind of mistake that I would expect to happen in an environment that produces that kind of garbage: Unless you are competent and do invest in quality assurance, that is exactly the kind of problem that noone will notice, as it does not affect day-to-day operation, and noone in the target market will notice if you screw it up because even the supposed experts think that the NAT implies that they are safe.

I suspect other network stacks or even ASICs have similar separation of concerns in order to be usable for a broader market than "home routers", so I suspect you can make the same mistake on other platforms used for implementing home routers.

So, do I know that there are devices out there that do NAT but don't filter? No. Would I be surprised if there were? No, definitely not.

However, if you do away with NAT, that makes it much more likely that a home router lacking a filter wouldn't go unnoticed for long, because it's trivial to check whether it does filter or not. So, it's not only that NAT does not logically imply a firewall and that a firewall does not necessitate NAT, but that not having a NAT makes it actually more likely that your device does in fact have a firewall.

Post reply on HN