As a middle-school CS teacher, I wrote a networking simulation [1] to help my students get a sense of how the packets get routed to their destinations. Importantly, it's vulnerable to spoofing, snooping, and censorship... students figure out how to do this mischief on their own, which leads to some great discussions of technical, policy, and ethical aspects of the Internet.
> a bunch of other stuff which I don’t understand that well (metric 600, scope link, proto kernel, etc). Not understanding what those things mean hasn’t hurt me yet.
These are pretty straightforward. metric 600 means that out of all the otherwise-identical routes, the kernel will prefer this one to one with a metric of 601 or greater. scope link means that this address is only valid on the local link (network interface). scope global means that (the kernel assumes) this address is valid on the wider Internet. proto kernel means that the kernel automatically installed this route for you because you used "ip address add x/y". Now, the "table x" part is actually really interesting, because Linux doesn't just support "a route table", it supports 256 routing tables. These are used in conjunction with policy routing in order to support source address routing, firewall mark based routing, and others. Firewall mark based routing is extremely powerful: for example: MARK all packets on port 53 whose (using BPF) first DNS query question is jvns.ca, and send those using eth1 instead of eth0. More mundanely, wg-quick from WireGuard uses this feature to bypass the VPN for the VPN packets, which allows the VPN to be used for the VPN gateway.
"This post is only about IPv4 because I’ve still never used IPv6."
IPv6 almost seems to be the networking equivalent of DAB radio at this point. A once futuristic tech that grew old in the tooth waiting for its moment.
At least IPv6 is getting developed and it's is easier to update than DAB, so one can hope that one day in the far future it becomes usable to people like me.
What's your main issue with its usability? v6 deployment is going up and looks like it's on track to replace v4, so the DAB analogy sounds a little diminuitive.
I get v6 on my mobile and on my broadband, and in all respects it seems to work well for making the internet end-to-end addressable again. With the devices like RPis and VMs/containers, the simplicity is refreshing vs hacks involving port forwards or using a for-$$ service as a proxy.
- IPv6 ready hardware. I went through several routers (Asus and similar), and it wasn't until I ended up with pfSense that IPv6 actually worked for more than a couple of hours.
- IPv6 ready software. Some software just gets slower when it first tries IPv6, fails and falls back to IPv4 (especially noticeable browsing the web). Some software gets all confused about IPv6 being present and stops working.
- IPv6 requires DNS, even with static prefix (I have dynamic prefix). For servers, that means per-server dynamic DNS entry. Very few DynDNS providers supports dynamic AAAA records, at least when I checked last year. And getting DynDNS clients working on the servers was a nightmare.
For IPv4 I just need to keep one DNS entry up to date, with plenty of DynDNS options all around.
- Dynamic prefix requires firewall rules to be updated when prefix changes. I wasn't able to figure out how to configure this in pfSense, though I admit I had lost some motivation at this point.
As a residential user who still gets a proper IPv4 address from my ISP, IPv6 doesn't really bring that much to the table. I still have to fiddle with my router/firewall, and at this point IPv4 NAT is a lot simpler to configure (linking rules to NAT entires for example).
> I went through several routers (Asus and similar), and it wasn't until I ended up with pfSense that IPv6 actually worked for more than a couple of hours.
This is not an IPv6 issue. Most cheap routers are garbage and cannot even handle newer IPv4 RFCs correctly. The other fault could be at your ISP. I need to ask mine for both a prefix delegation assignment and a non-temporary address assignment.
> IPv6 requires DNS, even with static prefix
False. You can statically assign whatever /64 host number you want to any interface, as many as you want per interface (for example you can bind each service you run to its own IP, to frustrate port scanning). You can use static assignment at the same time as IPv6 autoconfig, the latter is built to avoid collisions. This is a huge improvement on IPv4.
> Very few DynDNS providers supports dynamic AAAA records
So ask them. Or run your own DNS server.
> Dynamic prefix requires firewall rules to be updated when prefix changes.
That is the DHCPv6 client's job. You should be able to provide a script that the DHCPv6 client runs on server reply messages.
I am an IPv6 n00b, literally set up IPv6 on my home connection seven days ago, and have not stopped being excited about it since. No more fiddling with port forwarding garbage or configuring DHCPv4 to hand out reserved addresses for known MACs. IPv6 is an amazing improvement to IPv4 in so many ways. Wish I had taken the time to learn about IPv6 and set it up sooner.
It's not an IPv6 specification issue, correct. It is an IPv6 adoption issue. My ISP has provided IPv6 for 5 years, only last year did I get a router where it worked (apart from the other issues I've mentioned).
>> IPv6 requires DNS, even with static prefix
> False.
Of course it doesn't _technically_ require DNS, but in practice I'm not going to remember the 16 hex digits that is my prefix. And that's before SLAAC.
>> Dynamic prefix requires firewall rules to be updated when prefix changes.
> That is the DHCPv6 client's job. You should be able to provide a script that the DHCPv6 client runs on server reply messages.
Why should I have to provide a script? At most, I should be able to check a box on my router/firewall. Ideally I shouldn't have to mess with it at all.
I forgot to expand on the DAB analogy. My point was that they both tried to solve a problem nobody really had, and as such took over 20 years to really start to gain traction. By that time, the problem space had changed drastically.
For DAB, the rise of mobile data means far fewer listens to radio. Any audio quality increase turned out to be moot (they added more channels instead, besides streaming services has similar or better quality).
For IPv6, we now have a huge amount of actual clients (primarily mobile devices) with relatively few actual servers. In addition, security means companies use VPN or similar. This means the pool of devices who needs to be globally addressable is much smaller than it was. However the mobile devices can hop from network to network, and this isn't something IPv6 addresses any better than IPv4 (they'd still get a new address).
That's just my uninformed POV of course and I'm probably a bit harsh on IPv6 given all the frustrations I've had trying to get it working.
> However the mobile devices can hop from network to network, and this isn't something IPv6 addresses any better than IPv4 (they'd still get a new address).
In all fairness, it doesn't look like MIP is getting widely deployed any time soon. There is a currently active IETF group working on improvements, who knows, maybe it will get traction at some point: https://datatracker.ietf.org/wg/dmm/about/
Main issue is when you manage a TON of network devices.
What's easier - connecting to something your OOB management network (10.10.1.0/24) - the fw is 10.10.1.1, the switch is 10.10.1.11, the 5 servers are 10.10.1.21-26, etc etc...
That's a bit better than typing 2200:Hb43:4432:FE39:019H:F3Z6:3438:2101 etc...
I realize internal dns solves that, but that's a lot of extra dns records to maintain - which ALSO is an issue if your organization uses HSTS and preloads subdomains - you must have have a trusted certificate on each management interface, otherwise the browser simply won't let you manage those things over a GUI - or, of course, being your own CA and loading your intermediate and/or root into every deployed box on your network of every person that could potentially have to manage those devices over HTTPS.
That's literally my only issue with ipv6, in all honesty.
You really should have internal DNS records for everything, and internal reverse DNS that matches your IP address management system. Can't afford not to, for internal management networks. Also allows you to use autodiscovery and monitoring tools that discover and name devices by their rDNS. Having monitoring systems with hundreds to thousands of devices and things with only IP addresses and no hostnames is a nightmare.
You can use static assignment for the /64 host portion. Having a large prefix to work with for the subnetting actually makes managing a large number of devices easier because you can group them into logical subnets, and in a way that future-proofs expansion. Coffeen covers this in IPv6 Address Planning. And on top of that you get way more efficient routing.
The worst bit for me is server addressing. So my DNS server's have to be static, so I use ULA address for them, that's fine. But then everything else has a global address, and they change them frequently, so my DNS zone is filled with old invalid addresses, which then slows resolution, since clients are going through addresses to find the latest ones.
For most purposes, IPv6 works the same as v4 (only it has bigger addresses: 128-bit instead of 32-bit). Everything in the blog post works identically if you just swap in IPv6 addresses :)
If by "for most purposes" you mean something else than actually using IPv6 in a network.
For one, address allocation is entirely different. Devices will have several addresses, and some of them can be temporary addresses.
If your ISP assigns you dynamic prefixes (mine does), you can end up with devices not being able to connect to the internet after the router/modem reboots, since they're not told about the new prefix you just got from your ISP and happily keeps using the old one.
If your ISP assigns you dynamic prefixes (mine does), dynamic DNS is required for each server box (apparently one can centralize this by using DHCP-PD, but I haven't figured this out for my pfSense router).
And if you're writing an IPv6-enabled application, parsing client/server address input is a PITA compared to IPv4.
The list goes on and on, but these were the major pain points I found while trying to use IPv6 at home, which are non-existent when using IPv4.
But unstable prefixes are not a fundamental problem with IPv6, more of a teething problem where some ISPs may take some time to get clued in.
Meanwhile it never hurts to automate your handling of renumbering, it'll happen eventually anyway - just like letsencrypt short expiration times actually help you avoid cert expiration problems.
> If your ISP assigns you dynamic prefixes (mine does), you can end up with devices not being able to connect to the internet after the router/modem reboots, since they're not told about the new prefix you just got from your ISP and happily keeps using the old one.
You have a broken router setup, it's not doing router advertisement. Every reply of yours in this thread is just you complaining about something that you misconfigured on your router or did not bother reading about in any decent IPv6 introduction. Please stop the FUD.
Yes it's not what is currently (19 years after IPv6 RFC) considered best practices[1], but that's what my ISP hands me, so that's what I got to work with.
Either they really don't understand IPv6 or they are creating a false scarecity to charge you more money for what is essentially a free and virtually infinite resource to them, probably both.
Not sure what they're running. They do hand me a dynamic IPv4 address, but unless the modem is offline for more than an hour or so, I get the same address.
For whatever reason I get a new IPv6 prefix every time the modem or router reboots.
> For most purposes, IPv6 works the same as v4 (only it has bigger addresses: 128-bit instead of 32-bit)
That's the understatement of the year. IPv6 is a huge protocol and its complexity is its main weakness and one of the main reasons people and organizations stay away from it.
This is not true. They changed almost every detail in ipv6, from the address notation, to the fragmentation, to the peer discovery. Some of these may have been improvements, some not. But at the end of the day, all that anyone ever needed was a few more octets on the address. IPv4 with a couple extra dots would have been adopted 15 years ago.
> But at the end of the day, all that anyone ever needed was a few more octets on the address. IPv4 with a couple extra dots would have been adopted 15 years ago.
You are completely ignoring routing issues. IPv6 is designed from the ground up for efficient route aggregation, and more importantly the processes ARIN and RIR use for allocation are based around this. There is no way IPv4 routing would scale to what IPv6 is going to be in 10 years if you "just added" some octets. What are you going to do, force everyone to re-number?
Yeah, remember when IPSec was mandatory? And the two different schemes (never standardized I guess) that would have let you have a "home" IP address and a "network"/real IP address, so if you were streaming a video the source would send to one IP even as you hopped networks? Good times.
The funny thing is, there will be mandatory NAT on the carrier side during transition to IPv6 because of unwillingness of major websites to announce AAAA (including this one). See [0] for some transition method examples. The common theme of these methods is: They spoof DNS to point to fake IPv6 addresses, which is horrible, HORRIBLE, but hopefully motivates IPv4 holdouts to move to IPv6, announce AAAAs.
If you want to see what a wasteland IPv6 still currently is, and why such transition NAT madness will be necessary (sadly): Try disabling IPv4 when you have native IPv6 and your carrier has not enabled such DNS spoofing transition methods yet.
Horrible? Sure it's not ideal, but it allows carriers to go IPv6-only on their internal networks. Mobile carriers already put all IPv4 traffic behind a NAT, so this isn't a step backwards.
For most users, the transition will happen via dual-stack (where the customer runs their own IPv4 NAT), not NAT64.
Do you mean you turn off IPv6, because it's easy for others to get lots of IPs and bypass a IP blacklist?
If so, that is a difference from IPv4. Don't block IPs, block subnets. Block the whole /64. It's what you were doing with IPv4 anyway - blocking a whole building / office / etc at once!
That's still no reason to turn IPv6 off in my humble opinion...
Disagree. If you've only got IPv4 experience and have a number of possibly legacy devices on your network, then there is a significant amount of learning and changes required to make it work with IPv6 (securely).
It's entirely reasonable to say "It works fine without [=zero business value], no need to invest that amount of work.". This makes IPv6 a negative value proposition for many orgs.
I mostly focus on users of VPN services. It's still rare for them to handle IPv6 traffic. So if you have IPv6 connectivity, IPv6 will leak, bypassing the VPN. Unless you have firewall rules, or disable IPv6 while using the VPN.
I'm in India and my mobile service provider (Jio) is handing out ipv6 addresses. The fascinating thing about this is I was able to access a server hosted on my phone from Internet. Crazy!
> At least IPv6 is getting developed and it's is easier to update than DAB, so one can hope that one day in the far future it becomes usable to people like me.
Millions of people unknowningly use IPv6 every day: smartphone users on mobile networks. You either get an IPv4 address in 100.64.0.0/10 Carrier Grade NAT space or RFC1918 10.0.0.0/8 space, and a fully routeable IPv6 address. Your mobile application experience tends to be far better with services that can take advantage of native IPv6 connectivity.
if two routes to the same destination exist the kernel will (in general) use the one with the lower metric
proto kernel
this is where the route came from, for most end user hosts this will be kernel but if your box is running a dynamic routing protocol this might be something like "ospf", "bgp", etc; those protocols learn routes from neighbors and install them into the kernel routing table
scope link
this is information about the distance to the nexthop, in this case link means the nexthop is on the local network
I've got a bunch of static routes on my linux boxen using iproute2 tables to send traffic down the correct interfaces, do you think there's a better way using dynamic routing? If so what should I start googling?
If the topology is simple then managing static routes can be way easier than doing dynamic routing correctly, otherwise I'd start looking at BGP. Your best option right now in terms of software is FRR or bird.
But first you should understand dynamic routing and decide if it's right for your use case.
> a bunch of other stuff which I don’t understand that well (metric 600, scope link, proto kernel, etc). Not understanding what those things mean hasn’t hurt me yet.
This is what I like about Julia's writing - she is frank and tells you when she doesn't know.
Recently I discovered how weird IP addresses are on local machines:
Ping the following:
1.1.257
3.141592
0x01000001
198.2742178
All the fault of https://linux.die.net/man/3/inet_aton as everyone follows the implementation and there is no RFC on how to shorthand/collapse an IP address.
Yep. We used to use this to work around dumb HTTP content filters/firewalls with IP blacklists. Just convert the IP to decimal and try your request again. (Doesn't work so well now that the internet is huge and every IP hosts multiple virtual hosts)
wait, really? padding with zeros maps to a different IP address than the non-padded version?
Is that because a leading zero causes it to be interpreted as an octal number?
In [2]: socket.inet_aton('226.000.000.037')
Out[2]: b'\xe2\x00\x00\x1f'
In [3]: socket.inet_aton('226.000.000.37')
Out[3]: b'\xe2\x00\x00%'
In [4]: socket.inet_ntoa(b'\xe2\x00\x00\x1f')
Out[4]: '226.0.0.31'
In [5]: socket.inet_ntoa(b'\xe2\x00\x00%')
Out[5]: '226.0.0.37'
I wish there were more clarity in the point where your ISP sends the packet to "your computer." The packet goes to your modem, which is plugged into some network adapter (this is the network "device," right?). Then the network adapter sends the signal to another network device? That doesn't make sense to me. Certainly the network hardware receives the signal before the OS?
> The packet goes to your modem, which is plugged into some network adapter (this is the network "device," right?).
From the point of view of your OS' routing table, the "network device" is the OS device that represents the local network device. Ms Evans cites three examples; one's a real hardware WLAN device (likely connected to the system via PCIe or USB-via-PCIe).
The "modem" you're referring to is probably your or your ISP's "cable modem"? If so, the cable modem function of this device is (very nearly) transparent to the IP layer and we can ignore it for the sake of the routing table. I believe many/most of these modems function as a layer 2 bridge.
The sequence of events when packets arrive from the ISP is:
1. packet is forwarded from ISP to your cable modem.
2. cable modem receives the packet, sees that the destination address belongs on "this side" of the bridge and forwards it.
3. Computer's NIC ("network interface card") receives a packet, copies it into memory and interrupts the processor.
4. OS interrupt service routine handles the interrupt by posting a flag and copying the incoming data to another buffer.
5. OS' network stack realizes this packet is an IP packet and starts to process it according to local rules (next layer up, etc).
...lots of details omitted from above for the sake of clarity, but I can add more if you want. Slight variations of the above occur depending on the specific deployment of router-vs-cable-modem-vs-DSL-vs-NIC-config etc.
Ah, there it is! Okay, I know it's being pedantic, but the whole NIC aspect is what I was looking for. Taking my OS theory class at 8am was a bad choice. Thank you so much for the excellent explanation!
I am a bit confused by your question, but I can attmpt to help. A modem is short for a "modulator demodulator". In you question, an ISP modem converts one signal (DSL, cable, fiber, etc.) to another signal (ethernet). The Ethernet signal goes into a router, and the routers job is to make sense of where it goes. The ISP side is known as a WAN (Wide Area Network) and the internal network is the LAN (local Area network). The router keeps track of traffic to understand where to put it all. that traffic then goes to your computer.
I recently tried using a computer set up with only an IPv6 stack to do some websocket testing. Turned out that the websocket implementation in iOS version of WebKit (including iOS 12 beta4) still has some issues. Also most of the internet isn't connected. Ended up using 'show cached' from Google results a lot.
Every time I read an article or infographic by Julia Evans, I can't help but feel a bit of excitement, because even after 15+ years of linux/programming experience, I still learn something new every time.
I genuinely hope there are awards/accolades for people that bring this much value to the linux/programming/computing community.
I love her style. She knows a lot, but is VERY open to being wrong or not knowing things fully. That is to say, she's happy to say something that might not be 100% correct but is the way she understands it, or to admit she only knows 10% of this one thing. There's utterly zero arrogance but also there's not really a lack of confidence. It's almost a childlike wonder/excitement about things. In using that approach, it makes the reader appreciate the subject as well, feel happy about the things they know in common with Julia, feel happy about the things the reader knows that she doesn't know YET, and also feel comfortable that "hey, here's somebody else who ALSO doesn't understand this topic that well!" In every way, it's the exact opposite of imposter syndrome, both for the writer and for the reader.
I think too many of us (at least, based on my own experience) don't feel like we know enough to share with people. You both don't realize what you know that others don't, but are also anxious about being wrong or presenting yourself as an expert when you are not, for fear of ridicule or judgement or whatever.
Amusing anecdote. I'm entirely self-taught about computer stuff. I mean, it barely existed when I was a student. So anyway, descriptions of packet structure seemed so abstract and handwaivy. So for a few Ethernet and TCP/IP packets, I used Wireshark to get bytes from each field as hexadecimal, and crunched the data in Excel. It was incredibly tedious, but ultimately satisfying.
I've forgotten so much about networking. I just haven't had any need to use the knowledge since I learnt it in university. Back then I borrowed a copy of Tanenbaum's Computer Networks and it was great. I considered buying a copy for my bookshelf recently but it's very expensive now.
It makes me sad because when I was younger I seemed to remember everything forever. Now I realise there are large swathes that I've forgotten and most I probably don't even know I've forgotten.
I was just thinking last night about how valuable having taken a 200-level Computer Networks class is for me as a DevOps engineer. I use knowledge from that class almost every work day. TCP/IP and sometimes even Ethernet can be used to reason about all sorts of things.
At least you learned it (and from the same textbook I used in school. Dope!). It seems like a lot of universities treat their networks classes like an afterthought, but it is such a critical part of computation, and an incredible way to learn, and see demonstrated, principles that are far more general than just networks.
[1] https://github.com/cproctor/tcp-ip-simulation