Let's just get this out of the way before the debate commences:
DNS was invented in 1985 so that you don't have to memorise IP addresses.
DHCP was invented in 1984 so that you don't have to allocate IP addresses manually.
You can allocate nice short IPv6 addresses if you like to memorise hundreds of numbers as a hobby instead of letting the computer do that for you.
NAT is a hack for getting past the address-space limitations of IPv4.
NAT provides security as a side-effect.
Firewalls provide the same security.
Every router has a firewall built in now, whether they use NAT or not.
IPv6 has the same security as IPv4 whether or not you use NAT.
There are no "privacy issues" with IPv6. All modern clients randomise the host part of the address. You "look the same" to the rest of the Internet whether your unique address is a single IPv4 address or a /64 prefix. It's a unique identifier in both cases.
People that want to track you can use a hundred other techniques, most of which are more robust than your IP address. You're tracked anyway. Giving up on the future of the Internet in a futile attempt to stop your porn habits being tracked is not a valid argument against IPv6.
> You can allocate nice short IPv6 addresses if you like to memorise hundreds of numbers as a hobby instead of letting the computer do that for you.
You can not. Stateful DHCPv6 is poorly supported. In particular, Android doesn't support it, and I had problems with it on iOS. It's so niche at this point, that many companies (Mikrotik, I'm looking at you) don't even bother with it.
Moreover, even stateful DHCPv6 is a regression compared to V4 because it misses the host name. I can do a rough inventory of my IPv4 home network (120 devices) by looking at hostnames for DHCPv4 leases, no such thing exists for IPv6.
> I can do a rough inventory of my IPv4 home network (120 devices) by looking at hostnames for DHCPv4 leases, no such thing exists for IPv6.
You mean, you can do a rough inventory of IPv4 devices that are well-behaved and want to be found.
Unless you have enterprise-y network gear, which can do port isolation and preferably 802.1x auth, it's trivial for a host to poison your switch's ARP tables to check whether the address it wants to use it free, and then simply use that address without requesting it from the DHCP server[1].
The DHCP server will check that no hosts are using that address (usually via ICMP) before assigning any leases to it, but won't (at least for any common DHCP servers) register a lease for any host it discovers, so the rogue device doesn't even need to worry about changing addresses when a new host joins the network. At best, you might discover the presence of such a device by checking your DHCP server's logs.
Since no common consumer-grade NAT implementations check whether the internal host has a valid lease before establishing NAT state, the rogue internal device is free to communicate with any external host. Even better, the rogue device can send packets with a from-address of other devices on your network, allowing it to punch arbitrary holes in your NAT.
As other commenters mentioned, you can get a similar level network surveillance for IPv6 using mDNS, but at least IPv6 isn't lulling you into a false sense that you can see all the devices on your network in the lease table.
[1] Actually, it doesn't even need to do that... it can simply start using an address and then change to another address if connectivity seems to be a problem.
> You mean, you can do a rough inventory of IPv4 devices that are well-behaved and want to be found.
Incorrect. It's pretty trivial to allowlist on the firewall only hosts that have an active DHCPv4 lease. I've done it for my home network.
So you absolutely can have a rogue device, but it won't be able to connect to the Internet. This can be done with OpenWRT or Mikrotik (I have the latter).
ARP attacks, and MAC spoofing require an additional level of sophistication. With IPv6 you can legitimately have devices without any means to find out WTF they are.
> As other commenters mentioned, you can get a similar level network surveillance for IPv6 using mDNS, but at least IPv6 isn't lulling you into a false sense that you can see all the devices on your network in the lease table.
mDNS simply Does Not Work right now. Plenty of IPv6-capable devices don't support it.
No. mDNS is not mandatory (e.g. my TrippLite UPS management card doesn't support it), and it requires active device participation. If a device is busy or slow to respond, you'll miss it.
DHCPv4 leases are authoritative, and they don't require device participation for discovery.
Sending hostnames isn’t required for DHCPv4 either. If we want to talk about ill-behaved clients, I don’t see why you can count this as a negative for mDNS but not stateful DHCP.
In practice, hostnames are sent by most clients, because it requires pretty much zero effort from the device. mDNS requires a complicated service that needs to be always on.
Can you expand on the "All modern clients randomise the host part of the address" statement. Do they randomize this host part for every session or just once per network?
I've always been under the impression that it is actually easier to track an individual user on IPv6 because each device now has a unique address. Example Company could now tell the difference between 2 users in a home, for example, instead of just a single NAT'd IPv4 address. Is that not true?
IPv6 host can change its address as much as it wants. In fact, it can have as many addresses as it wants. It could use a different address for every outgoing connection. Nothing goes that far.
Most modern OSes change IPv6 every hour to once per day. The result is that any tracker can't tell if two IPv6 addresses in the same subnet are two hosts or one that changed its address.
How frequently the randomisation happens is configurable but the expectation is it should be ~daily. The thing you’re looking for is the SLAAC Privacy Extensions [1]
> Can you expand on the "All modern clients randomise the host part of the address" statement. Do they randomize this host part for every session or just once per network?
In practice, most OSes generate a new address once per day, but more significantly, it is completely normal for an IPv6 host to have multiple addresses per interface at the same time. In fact, it is effectively mandatory to have at least two:
First, you must have a link-local address (fe80::/10), which is non-routable. This is required for SLAAC and DHCPv6 to work. Second, if you want to talk to the rest of internet, you need a routable address (from SLAAC or DHCPv6).
In practice, it's even more than that:
The computer I'm writing this on currently has 12 IPv6 addresses on one ethernet interface. Besides the link-local address, it has as a bunch of routable addresses on the prefix delegated by my ISP. All but one of the routable are "deprecated" which means that they won't be used for new outgoing connections, but remain active for existing connections.
So not only do you get a new randomized address every 24 hours, you may have an arbitrary number of randomized addresses active at any given time.
There's nothing stopping a privacy-focused Linux distro from generating a new address for every outgoing connection, and having them all active at once.
Non–multicast-aware switches don't care; there aren't any additional unicast MAC addresses on the wire. Multicast-aware switches will incur multicast table growth, except in cases where multiple addresses on the same host share the same final 24 bits, which will cause them to share the same solicited-node multicast address (and therefore the same multicast MAC).
Most modern home routers have their IPv6 firewall enabled by default. (I am ignoring enterprise because the networking people there should already know firewalling)
In that context, the second statement can be true.
A misconfigured firewall is a gaping hole in your network regardless of whether NAT is involved. This means someone could brute force access into the configuration interface of your router and configure your network however they like.
NAT security is a dangerous illusion that people just can't seem to stop falling for.
The anonymous IPV4 network behind a NAT, which by default is inaccessible from the Internet and which, if it fails, just leaves the local network isolated, with IPv6 turns it a part of internet, accessible by default & design from internet with unique IPv6 for each computer and device, with the firewall as the only one separation.
The dangerous illusion is to think this is a coincidence.
> The anonymous IPV4 network behind a NAT, which by default is inaccessible from the Internet and which, if it fails, just leaves the local network isolated, with IPv6 turns it a part of internet, accessible by default
False, the default behavior is the same as IPv4/NAT. While the address scheme is technically "global", the firewall will still by default be blocking inbound connections to those addresses.
It is not unlike a random uuid or even a mac address in that the address is simply globally unique in nature, but not necessarily accessible unless you deliberately configure it to be, not unlike how one deliberately configures port forwarding in a local NAT based network firewall.
With IPv6 your ISP is giving your router an address "prefix" instead of just a single address as they usually do. The process of generating these addresses is therefore entirely local and anonymous from everything else on the Internet, obviously excluding hosts that are deliberately connected to who can then see the source address, but even in these cases your global address changes constantly so remote hosts still can't figure out your internal network topology. The reason these addresses are globally unique despite this is thanks to the ISP provided "prefix", which is essentially just a unique namespace.
>False, the default behavior is the same as IPv4/NAT.
The default behavior it is not the same as IPv4 with NAT, where the internet and local are different networks.
>It is not unlike a random uuid or even a mac address in that the address is simply globally unique in nature, but not necessarily accessible unless you deliberately configure it to be, not unlike how one deliberately configures port forwarding in a local NAT based network firewall.
The prefix the ISP gives to the router for to assign the IPv6 addresses to computers and devices it is the prefix of the unique uuid each one will get assigned. An unique IPv6 address is assigned to each one of these computers and devices, case contrary they would not be accessible from internet.
If the firewall fails or if it's shut down, all get exposed to internet, because IPv6 it is designed to make every computer and device part of the internet network by default & design.
Are you saying that every firewall misconfiguration that exposes any one host to the public Internet necessarily exposes control over the router configuration to the public Internet? I don't see how that follows.
No, I'm saying the firewall is what prevents access to the router's configuration interface regardless of whether you are using NAT. If you misconfigured it so that it was exposed and people could now break in, then all they would need to do after that is set up port forwarding to whatever internal host they want.
If you mean to imply that what I'm saying here is ridiculous because a "firewall misconfiguration that exposes any one (non-router) host to the public Internet" is only possible with a IPv6 or a NAT-less IPv4 network then you would be wrong (unless you were just being pedantic that I excluded such an example). A misconfigured firewall that exposes an internal host to the Internet would just look slightly different with NAT, since hosts are usually exposed via the firewall's port forwarding rules instead of the full featured allow/deny rules. There are technically going to be more firewall configuration options in NAT-less networks, but the risk of a misconfiguration accidentally exposing a host is not going to be any greater here.
If anything port forwarding actually encourages "accidental" exposure. They are usually kept in a separate interface from the other firewall rules, which indirectly encourages configurations that do blanket exposure to the Internet. Ideally internal networks should be configured to only allow inbound connections to specific host:ports from trusted external IPs/IP-ranges, but NAT makes this more complicated to do, so people get complacent with just exposing all inbound connections to specific host:ports because that is what port forwarding is usually going to default to absent of any other configuration.
> No, I'm saying the firewall is what prevents access to the router's configuration interface regardless of whether you are using NAT.
I still don't understand. Even if we assume that the configuration interface has no internal security (e.g., a strong password), how would a router with a NAT but with a totally busted firewall allow access to its configuration interface from arbitrary external hosts (short of having a forwarding rule for itself, which I suspect wouldn't even work on many routers)? What would such an inbound connection from an adversary look like?
> If anything port forwarding actually encourages "accidental" exposure. They are usually kept in a separate interface from the other firewall rules, which indirectly encourages configurations that do blanket exposure to the Internet.
It would seem to me like host-specific IPv6 firewall rules have their own challenges. Under IPv4 NATs, special internal hosts (that need their own rules) can be trivially assigned persistent labels through DHCP. With IPv6, if each host chooses its own address and rotates it regularly, then how are hosts persistently identified in the firewall rules? By MAC address? Or are there other systems for this?
> If you misconfigured it so that it was exposed and people could now break in, then all they would need to do after that is set up port forwarding to whatever internal host they want.
Why are these objections always "What if I configure my IPv6 network in worst way possible?"
Your router's configuration interface should be hosted on either a ULA or a link-local address, neither of which are routable. Security isn't the only reason you want to do that.
If you host the config interface on a globally-routable address, that address will change every time your ISP delegates your network a new prefix (which happens about as often as you would get a new external IPv4 address via DHCP). A router is the one of the few things on your network you should be able to access even without working DNS, so why do you want the config interface to be on an address than can change unexpectedly?
ULA and link-local addresses can be static: The network prefix will be static.
In IPv4, this is like asking "But what if I host my router's interface on the public assigned-by-DHCP IP?" My response would be "Why the hell would you host the config interface on an address that can change at any time?"
I've given up explaining things this way, it's too jargon heavy and skips over the fact that most people objecting to this are fundamentally misunderstanding critical details about how their networks operate. I suspect there is a degree of self-awareness regarding this which is why the concern can often be reduced down to: "I'm scared of fucking up my configuration, I have confidence in the levers I'm familiar with, but fear the levers I don't understand, so I hate them"
My hope is that by walking through it with simplified examples, this fear is mitigated.
In addition, the routers installed by ISPs are rarely updated and these firewalls will be very vulnerable. Until I get a router with NAT for IPv6, I'm not going to do anything with IPv6, I will even to change ISP if necessary.
> There is nothing in NAT what couldn't be done with DENY rule in the firewall.
I don't get the "false-security" issue with NAT.
I still need NAT if I can't allocate 1 IP per host, so if I create a NAT rule, why would I also need a firewall rule covering the same port (assuming default is DENY)?
"NAT is a security boundary" sits on using RFC1918 addresses and "nobody can enter my network because there is no DNAT rules for it!".
If you know how the routing actually works on Ethernet networks then it should be pretty obviously, but if not: there is no magic there.
If you know what the packet is addressed to some network not in your routing list, then you just throw it the default router with dstaddr of the recipient and MAC address of the default gateway. There is no security or anything.
And the same applies to the traffic you receive on the external interface. Anything what would be received on the external interface would be forwarded to your local networks if dstaddr of the packet is in your local network range.
And there is two ways to throw some packets with dstaddr in RFC1918 to your external interface:
a) be on the wire of your external interface - you can't forward those packets over Internet, obviously
b) have DNAT what would rewrite the IP of your external interface in dstaddr to some internal IP
So having internal addressing according to RFC1918 on the LAN and therefore using NAT to access anything else - doesn't make your network secure.
Usually this is not a problem, but if you are thinking what NAT do makes your network secure then you have two problems: possibly an unsecure network and feeling what your network is secure.
> why would I also need a firewall rule covering the same port (assuming default is DENY)?
EDIT: Oh, how quaint, just downvoting without responding. Remember, downvotes are not for your opinion on the comment.
But while we are at it, two more options on having an external packet traverse to your local network:
c) have a host on the LAN initiate a connection to the Internet, which opens up a port on the external interface of the router. Sure, in 99.9999% you can't use that, because the statefull firewall would discard the incoming packets not from the host which a client communicates... Until the attacker is that host in the first place, ie malware or even a deliberate operation
I didn't vote at your comment at all, so don't blame me. However you'll get an upvote from me now.
I agree about (some to most) of your writing and it was very informative (and lengthy!) but I didn't find the time to write something back which would honor your response enough.
> NAT provides a false sense of security as a side-effect.
Why?
> There is nothing in NAT what couldn't be done with DENY rule in the firewall.
DENY doesn't provide you stateful tracking. I.e. you want to let traffic between two hosts flow, but only if an internal host on your network initiated it.
And once you do that, you basically have 80% of NAT.
If you just want an address that isn't routable on the Internet then why don't you just use a local/wan ipv6 address? You can even have a local/wan address in addition to an Internet routable address at the same time, all without a hacky network address translation layer in your router.
Alternatively, if you mean local to external host connections, why would an inbound deny rule not work here?
> You can even have a local/wan address in addition to an Internet routable address at the same time, all without a hacky network address translation layer in your router.
Suppose that a host wants to open outbound connections to other hosts on the same network, as well as across the Internet, without regard to which kind of destination it is. By what mechanism does the host decide which source address to use? And how portable is this mechanism across different systems?
If you are Host A and want to connect to Host B, while simultaneously ensuring that your connection to host B is done over your local network; Then you would initiate this connection using "Local:Address:B"; and since it's prefix ("Local") matches the prefix of one of your addresses:"Local:Address:A", then your OS would automatically use that as it's source address.
Now if Host A connected to Host B via it's global address "Global:Address:B", then it would also work, but then Host A's connection would look like any other Internet address (and would still technically be routed over the internal network since it's the shortest path).
The router/firewall, which would sit in front of these two hosts, would still see this all as local traffic though, and in the vast majority of cases be configured by default to block all incoming traffic from outside the network. This means unless the firewall is configured to allow some kind of external connection into Host B, and Host B does not initiate the connection itself, then it would never actually see any global addresses from anything other than Host A.
> And how portable is this mechanism across different systems?
It's all about what address you use, so I could say portability would be limited to IPv6 support, but broadly speaking everything I've described here also applies to NAT-less IPv4 too, which is how most cloud VM networks are usually configured. Having both Local and Global addresses can be convenient in cases where you have multiple environments (ie: dev,stage,prod), since you can reuse most configurations referenceing internal system IP addresses.
> Then you would initiate this connection using "Local:Address:B"; and since it's prefix ("Local") matches the prefix of one of your addresses:"Local:Address:A", then your OS would automatically use that as it's source address.
This is the step that I'm particularly concerned about. Suppose that I have a Host B on my network, and I want to totally ensure that it has nothing to do with the global Internet, so I assign it only a local address and no global address. Then, I set up a local DNS service in my network, so that any host can ask for "Host.B" and get "Local:Address:B" back.
The problem is, will every kind of Host A, no matter what kind of embedded or IoT or corporate nonsense it's running, be able to properly manage both its local and global source addresses, and select its local address when it wants to connect to "Host.B"? This is a lot more to expect from a host than with IPv4 NAT, where Host A just uses its local address, and the router transparently handles the differences between local and global connections.
You don't actually need to use Local:Address:A as a source to connect to Local:Address:B, you can connect from Global:Address:A.
To make it more specific: if you advertise both 2001:db8:1::/64 and fd00::/64 as on-link on your network, a host can connect from 2001:db8:1::a to fd00::b, and fd00::b can reply to 2001:db8::a. Because both ranges are on-link, all communication is on-link and is never sent to the router. (This is just the normal behavior for on-link ranges.)
What if the two hosts have no link-level connection, and the router is the only thing connecting them? Would I need to have a fiddly rule in my router's firewall allowing connections to and from Host B only if the other host has either the local range or the proper global range?
Do you mean, say, one device that's on Ethernet and one that's on WiFi? Most people have their Ethernet and WiFi setups bridged so they count as the same link.
If you actually mean two separate networks, where traffic has to be routed via the router... obviously there's a lot of ways of setting up firewall rules, and it depends on exactly what you want to do, but the simplest approach is to say "deny new connections coming in via the WAN interface". This will allow new connections going out the WAN interface, and also allow all connections between the two local networks in both directions, with no need to specify any IP ranges in the firewall at all.
With even just IPv4 you can have multiple IP addresses assigned to one NIC, the one used will be determined based on your destination. This is a part of the protocol, having a local address and a global address was expected from the very begining with IPv4 (well more like having multiple IP addresses was expected), NAT was made as a bandaid to fix the fact that there weren't enough addresses to support this. Pretty much any VM you make in the cloud will actually follow this traditional model by default with each VM having it's own local and global IPv4 addresses at the same time. It's nothing special, you can expect every NIC to support this, this is basic stuff, you can expect it to work on everything every time.
Fundamentally all NAT does is simulate this kind of traditional network. It's an attempt to replicate this behavior by having all hosts "share" a global IP address that the router would then dynamically redirect back and forth based on which local host initiated the connection.
However the packets must physically pass through your firewall to get into your network. The IP addresses are simply an identifier to put onto the envelope, a firewall does not give a fuck about what the envelope says if a remote host attempts to initiate an inbound connection and this is forbidden (which it always is by default). Before a packet from the Internet even gets an opportunity to even get to the NAT part it is trashed. The firewall is the security guard at the door checking your badge, after that you go to the reception who "routes" you to the correct host. If an address isn't routable, which may be the case in a NAT network, then it's no big deal since you can just threaten the receptionist to tell you where to go
All NAT routers with Internet access will have both a local address and a global address natively, that's how it is even capable of sharing it's Global addresses in the first place, the firewall is what protects it, not NAT. If something can magically get past your firewall then that implies they have full control of your router now and can route packets wherever they like, remember this is hypothetical because breaking past a firewall is already a complete system failure, the boat has already sunk. At the end of the day it's all the same firmware, why would you trust the NAT part more than the Firewall part? It's literally just semantics.
> This is a lot more to expect from a host than with IPv4 NAT, where Host A just uses its local address, and the router transparently handles the differences between local and global connections.
I'm reiterating here but everything I've described so far is in relation to IPv4, all IPv6 introduces to the equation is: more addresses so you don't need NAT, a clever way to do dhcp on a local host without router intervention: SLAAC (routers can still advertise what to use as prefixes to these addresses). It also fuses together some of IPv4's extensions into one cohesive protocol that's simpler to understand. It's not nearly as radical as you may believe, it simply brings things back to how they were when IPv4 addresses were abundant and simplifies your firewall since you can easily configure which traffic can go to which host without involving weird port forwarding shenanigans.
Attachment to NAT for security is fundamentally a misunderstanding of what role it is serving, an assumption that it has more responsibilities than it actually does. It is not DHCP, it is not a Firewall. If you want to expose a local host to the Internet with NAT you configure the firewall to "forward the port" so inbound connections get redirected to your designated local host. If you want to expose a NAT-less local host to the Internet, you go to the firewall configure it to allow inbound connections with destinations set to your local host's global IP address and it's port.
FYI if you want you can have a static global address only used for inbound connections in addition to randomized globals for outbound connections. Though generally if you are setting up a server anonymous outbound connections are kinda pointless imo.
> It's nothing special, you can expect every NIC to support this, this is basic stuff, you can expect it to work on everything every time.
Even if every NIC supports it, how do I know that every OS supports it? Every system I've ever used has only needed a single address, so the multiple-address cases would seem to be a small minority (and mostly in networks with homogeneous systems), and not something I'd expect to be thoroughly tested on every random IoT device.
> If an address isn't routable, which may be the case in a NAT network, then it's no big deal since you can just threaten the receptionist to tell you where to go
What do you mean? If a host doesn't have its incoming connections forwarded from the router's global address, then how can it be accessed from the outside?
> If something can magically get past your firewall then that implies they have full control of your router now and can route packets wherever they like
You still haven't explained why this is the case. How does a firewall that exposes the router's address necessarily allow arbitrary control over the router? After all, I can access the router on my WAN all I want through its local address, and yet I'm still unable to reconfigure it.
> I'm reiterating here but everything I've described so far is in relation to IPv4, all IPv6 introduces to the equation is: more addresses so you don't need NAT, a clever way to do dhcp on a local host without router intervention
My big concern here is that I don't necessarily want every local host to be responsible for managing this, since I trust the router to have correct behavior far more than I trust every arbitrary host to have correct behavior.
> No. I want an address that can connect to the hosts on the Internet, but I don't want random hosts on the Internet to connect to it.
Gotcha glad we are on the same page now, so you do want the functionality of an inbound deny all rule, which is configured by default on all consumer routers, regardless of if they are IPv6 or even NAT/IPv4.
Why in the world, would you ever, want to expose all your local hosts to the Internet by default after all? That would be insanity.
You can have simple DENY for inbound TCP connections, because you can simply block incoming SYN packets. But inbound stateless DENY can't deal with UDP, as there is no connection.
So your options are either to prohibit UDP (goodbye QUIC) or to have stateful tracking.
The thing is, NOTHING in your post disputes that NAT provides very real, simple, and robust security for local networks. With NAT you simply can NOT make unsolicited connections to internal hosts.
It's not an illusion, it's actual security. Is it completely foolproof? No. But it definitely makes it easier to use, e.g. esp8266-based devices without worrying that they'd be knocked offline by an automated script that sends a couple megabits of traffic their way.
And to do the same on IPv6 you need 80% of NAT, in particular you need stateful connection tracking.
You simply can. NAT doesn't give any security whatsoever. Here's an unsolicited connection to an internal host over a router that's doing NAT:
(192.168.0.101)$ echo "Hello from inside" | nc -vlp5000
Connection from [203.0.113.1] port 5000 [tcp/*] accepted (family 2, sport 36596)
(203.0.113.1)$ nc 192.168.0.101 5000
Hello from inside
And here's the 3-way handshake captured on the router:
wan0 In IP 203.0.113.1.36854 > 192.168.0.101.5000: Flags [S]
lan0 Out IP 203.0.113.1.36854 > 192.168.0.101.5000: Flags [S]
lan0 In IP 192.168.0.101.5000 > 203.0.113.1.36854: Flags [S.]
wan0 Out IP 192.168.0.101.5000 > 203.0.113.1.36854: Flags [S.]
wan0 In IP 203.0.113.1.36854 > 192.168.0.101.5000: Flags [.]
lan0 Out IP 203.0.113.1.36854 > 192.168.0.101.5000: Flags [.]
See? It works just fine. Here's the other direction, just in case you think I wasn't NATing:
lan0 In IP 192.168.0.101.44682 > 203.0.113.1.5000: Flags [S]
wan0 Out IP 203.0.113.58.44682 > 203.0.113.1.5000: Flags [S]
(If you want to see any aspect of the config, just ask. Give me commands to run if you want.)
The fact that it works at all disproves your "you can't do it" claim.
I didn't misconfigure the router here. Please ask for whatever config info would convince you of that. It's true that most router devices you buy (presumably including Mikrotik) do block inbound connections by default, but they do it with a firewall, not with NAT. The reason they need the firewall is because NAT doesn't do it.
Yes, it is correct. You can't do it in practice, because it requires you to control the ISP.
This automatically makes it a non-issue for pretty much all home and small office networks. Meanwhile, the DEFAULT state for IPv6 is being open to the world.
> I didn't misconfigure the router here. Please ask for whatever config info would convince you of that.
OK. How can I ping your address? It should be easy, right? I'll even give you my IP: 208.52.76.162 , what do I need to set up to be able to ping all your internal hosts?
You can't do it in practice because everybody has firewalls, and also widespread use of RFC1918 in v4 makes it hard to even send the right packets to the right place. I wasn't arguing that; my point was just that NAT won't stop any inbound connection, and if your inbound connections are being stopped by something... then the something isn't NAT.
> OK. How can I ping your address? It should be easy, right? I'll even give you my IP: 208.52.76.162 , what do I need to set up to be able to ping all your internal hosts?
> Let's make that experiment.
Sure. Since I'm using RFC1918 on the inside you'll need to be on my immediate upstream segment to test this, so I set up a gre tunnel for you. If you're on Linux you can run something like this (otherwise I'll leave it up to you to map the tunnel setup to whatever you're using):
$ ip netns add temp
$ ip link add gretap type gretap local 208.52.76.162 remote 151.115.75.246
$ ip link set netns temp gretap
$ ip netns exec temp "$SHELL"
(inside netns)$ ip link set up dev gretap
(inside netns)$ ip addr add 203.0.113.150/24 dev gretap
That will put you on my upstream segment, outside of my NATed network, using 203.0.113.150. Then just do this:
(inside netns)$ ip route add 192.168.0.0/24 via 203.0.113.58
(inside netns)$ ping 192.168.0.101
> I wasn't arguing that; my point was just that NAT won't stop any inbound connection, and if your inbound connections are being stopped by something... then the something isn't NAT.
NAT _will_ stop inbound connections in practice, unless you control the ISP. So in practice NAT provides more than enough security for typical SOHO users.
> Sure. Since I'm using RFC1918 on the inside you'll need to be on my immediate upstream segment to test this
Exactly. Which means that you need (in practice) to control the ISP for this attack to work.
No, it won't. All that's needed is an inbound route to your router, and NAT can't prevent that route from existing. It doesn't matter if you have ISP control or not.
I'm not seeing any gre packets from you. Are you having trouble getting the tunnel working?
Hi, Condointernet/WaveG/Astound user. I've used their network before, and from experience, they put you on the same L2 segment as your neighbors. There's ARP/DHCP/etc filtering in place on the switch to prevent most kinds of shenanigans, but your neighbors can still send packets with a RFC1918 dst IP to your Ethernet address.
To ping your internal hosts, I'd need to gain access to your building or one sharing the same L2 segment ("dfsea"?), then configure a static route for 10/8 / 192.168/16 / etc pointing at you. I would not need any control over the ISP.
That's fantastic for you, and for DOCSIS users (setting aside DOCSIS' other pain points), but your neighbors on residential Ethernet-based plans do not enjoy the supposed security benefits of NAT that you claimed upthread.
Accepting packages that are part of an established connection are a standard option form IP table configurations.
And if you want to do something like host a minecraft server on your computer that you can then let your friends access (and only your friends), you need a firewall config anyway.
The loudest people arguing against IPv6 are often hiding the kind of behaviour I really don’t care to protect. Drug purchases on the dark web or exchanging child porn are common reasons to be this paranoid.
Normal people just use a VPN or a cloud proxy and move on with their lives.
It’s all academic anyway. It’s hilariously easy and effective to build up an identity via browser fingerprinting, or similar techniques. Ironically, the more crazy “protections” you layer on, the more special and distinct that fingerprint becomes.
As a case in point: running a Tor client makes you a high priory target for the NSA and similar state agencies. To the point that something like half of all Tor nodes are rumored to be compromised!
PS: IPv6 is such a vast number space that brute force scanning the Internet to look for vulnerabilities will go from a “hilariously simple Python script” to “literally impossible”! People worried about security and privacy should be rushing to switch to IPv6 because it’ll permanently block all drive-by attacks!
> The loudest people arguing against IPv6 are often hiding the kind of behaviour I really don’t care to protect. Drug purchases on the dark web or exchanging child porn are common reasons to be this paranoid.
> Normal people just use a VPN or a cloud proxy [...]
Ad hominem
<< The most common form of this fallacy is "A" makes a claim of "fact," to which "B" asserts that "A" has a personal trait, quality or physical attribute that is repugnant thereby going entirely off-topic [...] >>
Unfortunately, this is the sad reality of the situation. I've seen a number of online arguments where someone was "fighting the good fight" against corporate censorship, getting their account locked for "no reason", or whatever. In a few such cases the site admin responded with "you're a relentless spammer, that is why you were banned". Or in one such case, "you were sending unsolicited dick picks to underage girls".
Not everyone is nice. Some people's ideal for the Internet is not my ideal for the Internet. I don't have to agree with everyone, and I don't think infinite protections should be granted to people like that at great cost to everyone else.
On the other hand, the grandparent comment (by guilhas) was engaging in strawman fallacy by misconstruing the top comment (by jiggawatts):
> Giving up on the future of the Internet in a futile attempt to stop your porn habits being tracked is not a valid argument against IPv6
should certainly not be simplified into
> If you have nothing to hide, you have nothing to fear
in the context of the full original comment which mentioned that hiding behind an CGNAT IP address is _not_ hiding, given that other more robust (and already prevalent) methods of tracking exist.
Obviously, two wrongs do not make a right, but since we are already talking about logical fallacies I might as well warn all the readers here that this thread is full of 'em - take the comments with a grain of salt.
The logic of that remarked Ad hominem is to hide details of your IP by paying additional services, because depreciable and disgusting people does it for free.
He's not wrong though, although the way he put it was harsh. You can't truly hide your IP with mere CGNAT. Epsecially when modern CGNAT is all about "how to log the 5-tuple efficiently?"[0]
You need a log-less VPN service at the very least if you desire true privacy. Otherwise, IPv6 with privacy extension will achieve the same effect as CGNAT.
I think it would be logical to assume that the aforementioned depreciable and disgusting people are already using Tor or VPNs/ proxies.
There is no problem at all with the police or Interpol wanting to track a CGNAT map requested to the ISP through legal channels. This is why ISPs are required by law to retain the logs.
The privacy extension is for use on the rest of internet.
> So if I have 1000 devices I have to advertise every single one to my ISP?
Generally: No, if they use Prefix Delegation (which is what most non-mobile ISPs use). Your router sends a DHCPv6-PD request and the ISP delegates a /48 (usually) or /64 (if they are run by morons) prefix to your router. Your router advertises that prefix on the local network, and hosts self-assign addresses within that prefix.
> Couldn't they start a pricing based on how many devices I have?
Most OSes generate new random addresses every 24 hours (and keep old addresses with open connections), so there is no reliable way for your ISP to determine how many hosts are on your network.
It is easier to determine number of devices using network flows and DNS queries than it is to use IPv6 because of the many privacy extensions in use today.
As the other poster said, Stellar. At the end I was reading about mobile IP issues, and a voice in my head said I bet he doesn't mention QUIC. Then he mentioned it. Which makes it the most complete piece I've read on IP routing.
> We'll need to keep running a local DHCP server at home so that our obsolete IPv4 light bulbs keep working. We'll keep needing NAT so that our obsolete IPv4 light bulbs can keep reaching the Internet.
It's not really, it just spends a lot of time waffling on about bus networks and mobile IPs and then makes some weird claims about the IETF that don't seem to match reality.
v6 is designed the way it is precisely because it needs to run on the same networks that v4 does, and v6 is a better design than v4 in our world because our world has completely outgrown v4.
the reverse lookup domain name corresponding to the address
4321:0:1:2:3:4:567:89ab
would be
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
ARPA.
Honestly quite a horrible reference for people new to IPv6. Seems like the author was more concerned with flexing how much they know about IPv6 than teaching anyone how to use it. In that rambling, wall of text and literal packet dumps no where are they even close to:
1. Explaining the basic details about IPv6's address model (e.g. what is link-local, what is global scope? where should one use them?)
2. Letting anyone make an IPv6 connection to various address types (gee, would be useful, right? Kinda the point, no?)
3. Maybe letting someone use their browser to connect to an IPv6 address. (also helpful as it would show the above catches.)
4. Hosting services that use IPv6 in software.
Can you really blame people for not using IPv6 when people try pull this shit.
Which parts are outdated? It mostly looks like an explanation of IPv6 networking fundamentals, such as how DHCPv6 works. I wouldn't expect those to change substantially based on OS version.
"DNS was invented so that you don't have to memorise IP addresses."
Prior to DNS it was necessary to have all the IP addresses one needed stored in a local file, HOSTS.TXT. It was not necessary to to memorise the addresses stored in this file. Memorisation of IP addresses was never a requirement to use the internet.
To this day, /etc/hosts allows me to avoid memorising IP addresses. No DNS required. But more importantly it allows me to avoid _having to type_ either IP addresses or domain names. I can assign short strings in place of typing addresses or domain names.
Now I can type "ftp1" instead of having to remember 5.179.1.4 or ftp.lanet.lv
echo ls |ftp ftp://ftp1/pub
There are some useful IPv4 addresses that I did memorise over the years.
For example, by memorising a root server address such as 198.41.0.4 I can lookup the IP address for any domain name, using non-recursive queries to only authoritative DNS servers, without using a DNS cache like 8.8.8.8 or some other third party DNS "service". All I need is a stub resolver, like dnsq, drill or dq.
By memorising the IP address of a .com nameserver, such as 192.5.6.30, I can lookup any .com domain name using the same non-recursive methodology. All the third party DNS caches could be poisoned, have outages or whatever. I would not need any of them to continue using the web.
And by memorising the address for getting a copy of the root zone, i.e., 192.0.32.9, I can avoid having to make DNS queries to find out the namservers for any TLD. I can use HTTP or FTP to retrieve the zone data.
ftp -4 ftp://192.0.32.9/pub/root.zone
As it happpens I store lots of historical DNS data so if there was a massive DNS outage I can still continue using the web uninterrupted. Day-to-day I'm not using remote DNS much. I'm using stored DNS data retrieved in bulk at some time point in the past. For the data I retrieve, very few addresses change often if at all.
I like IPv4. I think it will be around for the duration of my lifetime. It works everywhere and I like reliability. I disable IPv6 on the computers I can fully control. (Obviously "smartphones" are excluded from the list, that's why they suck as computers.) When compiling software that has "--disable-IPv6" as a configure option, I always disable IPv6. I also disable getaddrinfo() when it's an option. I prefer gethostbyname().
While I am not concerned with memorising every IP address I use, I do type and search IP addresses quite frequently; I work with addresses at the command prompt as parameters to command line utilties and in files, such as /etc/hosts and much larger files that contain hundreds of thousands of IP addresses, often using an editor such as ed, sed, vi or custom filters I have written in C. Needless to say, IPv4 addresses are easier to work with.
When I check weather I use an IP address not a domain name. This can be quite useful on a smartphone where I generally cannot control DNS. This is an IPv4 address. As one might imagine, I have memorised it. Often this will work on public wifi without having to "sign in".
DNS was invented in 1985 so that you don't have to memorise IP addresses.
DHCP was invented in 1984 so that you don't have to allocate IP addresses manually.
You can allocate nice short IPv6 addresses if you like to memorise hundreds of numbers as a hobby instead of letting the computer do that for you.
NAT is a hack for getting past the address-space limitations of IPv4.
NAT provides security as a side-effect.
Firewalls provide the same security.
Every router has a firewall built in now, whether they use NAT or not.
IPv6 has the same security as IPv4 whether or not you use NAT.
There are no "privacy issues" with IPv6. All modern clients randomise the host part of the address. You "look the same" to the rest of the Internet whether your unique address is a single IPv4 address or a /64 prefix. It's a unique identifier in both cases.
People that want to track you can use a hundred other techniques, most of which are more robust than your IP address. You're tracked anyway. Giving up on the future of the Internet in a futile attempt to stop your porn habits being tracked is not a valid argument against IPv6.