PDFs from tools.ietf.org are still available on their previous URLs. like for rfc791 it is https://tools.ietf.org/pdf/rfc791.pdf
(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.
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
Not to mention speculation https://news.ycombinator.com/item?id=19923519
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.
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!
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)
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…
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.
> 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.
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)?