RFC 791: Internet Protocol (1981)
datatracker.ietf.orgPDFs 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
Today, IETF uses Cloudlfare.
(Although the same old IETF IP addresses can still be accessed directly, e.g., 4.31.198.44.)
I have always used a one line script to fetch the text versions of RFCs. It has always been the fastest. In the early days all RFCs were plain text, no HTML.
Something like below except I use custom programs for HTTP generation, chunked transfer decoding and ESNI-enabled openssl. Also they allow RFC2616 HTTP pipelining so I can retrieve multiple RFCs with one TCP connection.
(104.16.0.0./12 is one of many Cloudflare blocks that can be used.)test $# = 1||exec echo usage: $0 rfc-no\|draft-id printf "GET /rfc/rfc$1.txt HTTP/1.0\r\nHost: www.ietf.org\r\nConnection: close\r\n\r\n"|openssl s_client -tls1_3 -4 -servername www.ietf.org -ign_eof -connect 104.16.249.249:443|less
And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
I suspect that one of the reasons why ipv6 is being held back is because of people who hoard IPv4 addresses have an interest to gatekeep them so that they can rent them to you.
Not to mention speculation https://news.ycombinator.com/item?id=19923519
Compare IPv6 adoption to that other generational migration of our time: 32-bit x86 to 64-bit x86. The first x86-64 CPUs became available in 1999, while 32-bit Windows will still be supported through to 2025 on Windows 10. Only with Windows 11 will the world’s mainstream OS finally complete the move away from 32-bit.
IPv6 migration is much more complex, so I don’t think we’re doing too badly, and I think we’ll be done around 2040.
64 bit adoption was far faster. A mere decade after x86_64 was available, just about the entire consumer market switched. The last barely-mainstream 32bit processors were of the Intel Atom line (for notebook), and that ended about a decade ago. Microsoft's backward compatibility guarantee makes the timeline look much longer than it actually is.
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 porting to a 64 bit RISC which coincidentally were all dying or dead at the time. The only other option at the time was IA64 - Itanium - which sucked and was way more expensive.
The value prop of v6 is: ??? Learn an entirely new networking stack! Enjoy degraded service because v6 will cause inexplicable hangs and timeouts! Deal with a weird ass protocol founded on perimeter security which is not something we have been doing for 20 years! Fun for the whole family!
> The value prop of v6 is: ??? Learn an entirely new networking stack!
The value prop of IPv6 is not having to pay US$ 30/IP (and rising) when you need a block of new IPs. Most folks don't need that many public IPs and so simply use RFC 1918 addresses and then implement the kludge that is NAT. NA(P)T was codified in 1999 (RFC 2663), and it is now "background radiation" so people think it's normal because it's all that they've ever know.
But we've long gotten to the point where we're now doing double-(CG)NAT, and entire chunk of address space (100.64.0.0/10) has been reserved just for this purpose:
* https://en.wikipedia.org/wiki/IPv4_shared_address_space
I'm waiting for triple-NATing to start occurring.
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.
Does the CGNAT setup you contend with not support NAT-PMP/PCP? (To me that is the reasonable solution to the problem you cite, not IPv6, and I have been thinking it is already widely deployed... just not adopted by developers for some reason.)
I don't contend with CGNAT, thankfully, but no one ever moves from IPv4 then everyone's going to eventually be behind a CGNAT at some point.
I don't know too much about NAT-PMP/PCP - so I'm looking into it.
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.
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.
It isn’t specific to WiFi: there is the same problem if you use SLIP or PPP dial-up or DSL or cellular data, or many kinds of VPN.
And for IPv6 over ethernet, ND proxying is not a protocol you would normally use to construct a network.
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.
> The possibility of having a private v6 network was added much later (some time in the 2000s I think?).
ULA seems to be RFC 4193 (October 2005). NTPv6 is RFC 6296 (June 2011).
I'm not a network guy, so forgive my ignorance, but this is the first time I'm hearing about this. Why will IPv6 cause inexplicable hangs and timeouts?
When a server has IPv4 and IPv6 connectivity, i.e. an A and AAAA DNS record, clients would usually try IPv6 first, then IPv4. Now, if IPv6 is broken somehow (as it was prone to be due to tunneling, Teredo and even nowadays stupid ISPs), the client would wait for a connection timeout, then try IPv4, so every connection would hang for one timeout.
Nowadays, most clients, especially browsers, will try IPv4 and IPv6 concurrently and use the connection that comes back with an ack first. This prevents hangs at the expense of a little higher server resource usage.
But the myth of "IPv6 makes things hang randomly" remains.
It's not a myth when it happens. Last time I tried v6 again on my network (about a year ago) I had these issues. Not a lot of them, but toggling v6 off made them go away. There are fewer issues, true, but having dual-stack does still appear to break some things. I say "appear to" because I'm assuming that it's not actually an issue with v4+v6 dual stack, but rather a problem with misconfigured services (e.g. services having wrong AAAA records, stuff using v6 that doesn't work properly with v6 etc.); from an end-user perspective this does not really matter: There are sometimes issues when v6 is on, which go away by turning v6 off - end user perception: v6 is wonky.
Your lived experience is what it is, and I certainly don't mean to contradict you. But just to add another viewpoint for perspective...
My ISP (formerly Time Warner, now Spectrum) has been handing out v6 addresses here, and I've been running in dual stack mode, for a good 3 years or more now. And in all that time, I can remember exactly one occasion where IPv6 caused any issue. And that was only because somebody at my employer who was setting up a GCP environment didn't take into account that anybody would be coming in on IPv6, didn't configure the corresponding firewall rules, and it broke using kubectl to access GKS clusters from my home network, as kubectl was defaulting to the v6 connection.
So yeah, v6 can cause some weirdness, even now (the event described above was about 3 months ago) but in my experience it is exceedingly rare. YMMV, of course.
I use Spectrum and their IPv6 connectivity drops out relatively frequently, but IPv4 connectivity stays.
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.
Not sure about operating system readiness besides the presence of an ipv6 stack though.
Can you imagine most consumer pc, barely updated, being publicly exposed?
Can you imagine the average senile pc user having to deal with a firewall? firewall exceptions?
NGL I have ipv6 at home but made sure it's disabled at my parents' home. It's just a recipe for disasters.
I'm well aware that ipv4+nat is not "security"... yet it removes a whole class of problem (eg: windows print spooler is listening on [::] by default or something like that)
EDIT: and some appliances too. I had to check twice last time I got a network enabled printer... It has an ipv6 stack, I had ipv6 enabled at home, and it had got a public ipv6 (besides the ULA address and the link-local address) and it was happily listening on the public internet for something to print.
I have looked at some consumer internet routers and there's still not enough ipv6 firewalling at router/gateway level (which become a necessity when NAT is lifted)
> I'm well aware that ipv4+nat is not "security"... yet it removes a whole class of problem (eg: windows print spooler is listening on [::] by default or something like that)
IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4.
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table/s it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.
With IPv6 address/port, rewriting is not done. Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
The security comes from the state checking.
> […] and it was happily listening on the public internet for something to print.
I have a printer with an IPv6 stack. I also have IPv6 addresses from my ISP. Yet somehow my Asus AC-68U prevents the public Internet from reaching my printer…
> There's no magical security behind NAT
That's exactly the point. Yes, I know the "security" NAPTv4 provides is just a side effect. But it is what was widely deployed in the field. If you want to push IPv6, you MUST make sure in field appliances match this "side effect" (as a properly implemented firewall).
And this is not happening.
NAPTv4 with a "block incoming connection" side effect is widely deployed, running on countless CPEs. Proper IPv6 firewall is not. Thus IPv6 is not ready for these users.
> NAPTv4 with a "block incoming connection" side effect is widely deployed, running on countless CPEs. Proper IPv6 firewall is not.
I've been running IPv6 through my Asus for years now and it's been no different than IPv4. Going to Advanced Settings > Firewall, under "IPv6 Firewall" it says:
> All outbound traffic coming from IPv6 hosts on your LAN is allowed, as well as related inbound traffic. Any other inbound traffic must be specifically allowed here.
It then has a table where you specify traffic to be allowed in to specific internal hosts on particular port (ranges), but since this is IPv6, you don't have to deal with reverse-NATing now.
> IPv4+NAT does not remove any more classes of problems than IPv6+firewall
NAT is automatic and works out of the box while most users, even tech-savvy ones don't bother configuring the firewall on their own laptop, let alone on the router/gateway.
And by the way, I'd like to see you explain that firewall thing to the average senile pc user (grandma/grampa).
There is nothing to figure out: you take your Linksys/Asus/whatever device, plug in the WAN side to your modem, and your computer(s) to the LAN ports. Perhaps enter your credentials if you're using PPPoE, and you're done.
I'm not sure why you think IPv6 is more complicated than IPv4 for home users when it comes to CPEs.
What exactly do you think needs to be done on an Asus/Linksys for IPv6 protection that is different than IPv4?
Adding the right rules for a firewall is not more difficult for IPv6 than for IPv4 with NAT, if anything it is simpler.
It is true that usually NAT is configured by default to not accept connections from outside to inside, but any firewall should have default rules that forbid such connections for any protocol, both for IPv4 and for IPv6.
Nonetheless, you are probably right that many, maybe most, home routers/firewalls might come with bad default configurations, where instead of having sane default rules for IPv6, there might be just a default rule to pass all.
If that is the case, it is not the fault of IPv6 but of the device manufacturers. For NAT it is also possible to put stupid default firewall rules, that just is less common, because almost all customers use NAT and the bad defaults are frequently noticed and reported.
Most consumer NATs are intentionally configured to be leaky. A commonly used technique is hole punching (https://en.wikipedia.org/wiki/Hole_punching_(networking) ), which all consumer NATs are prone to support because otherwise many popular applications such as games, voice- and videoconferencing won't work. There are also formally specified protocols to expose hosts to connections from outside: https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc... https://en.wikipedia.org/wiki/Port_Control_Protocol and others. All this is done with no or poor authentication, so any malware that managed to make it inside your network (e.g. by a guest carrying an infected device) can just request your home router to open ports. There have even been problems where such protocols were open to the outside internet, of course without auth. There have been problems with misdirected exposed ports when hosts go offline and addresses are reassigned. Those just don't make headline news because the protocols work as intended and each misconfiguration is unique, automatic and temporary.
So, first, your IPv4 NAT has crappy security already, by virtue of needing to accomodate services like realtime audio/video/control that won't work properly without incoming connections. Second, IPv6 is supported in the same way, PCP can just do the same for IPv6 firewall rules as it does for IPv4 NAT exposed ports.
There is absolutely no reason to not use IPv4 over IPv6, it'll work the same from an end-user's view. But it'll be slightly less messy because you just configure firewall rules per IPv6 address instead of translating the limited port space of your one external IPv4 address into a number of internal Port/IPv4 combinations. So the chance to screw up is lessened.
> it'll be slightly less messy because you just configure firewall rules per IPv6 address instead of translating the limited port space of your one external IPv4 address into a number of internal Port/IPv4 combinations. So the chance to screw up is lessened.
as mentioned, with ipv6 you now have to care/worry about multiple classes of numbers, so i'd argue that because the number-space is increased, so is the chance to screw up.
i grew up with windows 3.x computers having a public ip and no firewall and as nice as incoming connections by default are for an enthusiast, they are a unecessary danger for the masses.
as you said, hole-punching works on ipv6 as well and has to be initiated from the inside, so it's no argument for .
I do not know what you mean by "multiple classes of numbers".
A firewall must block everything by default.
You add then exceptions for the protocols, hosts and ports that you want to allow.
Regardless whether you use IPv4 or IPV6, you have the same number of protocols, hosts and ports for which you must add rules.
The only disadvantage of IPv6 is that you should be more careful when you copy and paste the host addresses into rules, because the IPv6 addresses are longer and it might be more difficult to notice typing errors in them.
On the other hand, you no longer need to add NAT rules.
i was refering to the multiple classes of ipv6 addresses. most ppl don't care about a clever numbering sheme and probably wouldn't if they understood.
does the firewall discard extension headers from the internets? what about relevant icmp?
public/private interface? ah right, can't tell from a look at the address...
nat-rules are very simple by comparison.
don't get me wrong; i am very happy with adopting an incompatible, new internet protocol for all the app- and smart-shiit.
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 connections by default (but can be easily punched, even automatically by NAT-PMP, UPnP and a bunch of other protocols).
Lifting the NAT doesn't mean lifting the firewall: new ISPs that deployed native IPv6 are doing exactly the same firewalling as before.
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.
Exposing by default or not does not have anything to do with NAT.
It only depends on the default firewall rules.
The default rules should not allow connections from outside, regardless whether NAT is used or not and regardless whether IPv6 is used or not.
Any device with a network interface connected directly to Internet must have an active firewall.
Whoever downvoted this does not know how NAT and firewalls function.
That NAT and firewall are independent functions, even if they may be performed by the same program, is a simple true fact, which cannot be contested.
NAT cannot enhance security in any way. On the contrary, only the absence of any NAT can enhance the security of private IPv4 networks, because only when NAT does not exist, the computers with private addresses are no longer reachable from outside. Whenever a device that does NAT exists in your network, your internal private addresses become public addresses, no longer hidden from the Internet, because that is what NAT does. The fact that multiple internal addresses are mapped to a single external address may make more difficult the tracking of individual users, but it does not protect the internal computers in any way from external accesses. That is the job of the firewall, which filters the undesirable IP packets.
So anyone who believes that NAT is something that provides security is delusional.
I own a subnetwork of public IPv4 addresses and I have a private network of computers connected to the Internet through a router/firewall, which is a standard PC on which I have been managing the firewall and NAT for almost 20 years.
Neither of my 2 ISP's supports IPv6, so I use IPv4 with NAT.
However, if I could use IPv6, rewriting the firewall rules would not take more than a few minutes and the security would be exactly the same as it is with IPv4 and NAT.
> 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?
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.
> […] and it had got a public ipv6 (besides the ULA address and the link-local address) and it was happily listening on the public internet for something to print.
Another thought: perhaps 'appliances' should (by default? togglable?) have only ULA and link-local addresses? Basically anything that starts with "f" (fe80::/10, fc00::/7, multicast)?
Happy birthday!