Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 791: Internet Protocol (1981)

datatracker.ietf.org

Post reply on HN
Print view View original

31–40 of 45 posts

Re: RFC 791: Internet Protocol (1981)

#31

Post by throw0101a »

formerly_proven wrote: post #26
fanf2 wrote: post #23

Earlier quoted context omitted.

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 t…

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…

> 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).

* https://datatracker.ietf.org/doc/html/rfc4193

* https://datatracker.ietf.org/doc/html/rfc6296

Re: RFC 791: Internet Protocol (1981)

#33

Post by 1vuio0pswjnm7 »

minroot wrote: post #24

PDFs 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.

   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
(104.16.0.0./12 is one of many Cloudflare blocks that can be used.)

Re: RFC 791: Internet Protocol (1981)

#34

Post by throw0101a »

znpy wrote: post #4
diea wrote: post #2

And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200

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 i…

> […] 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)?

Re: RFC 791: Internet Protocol (1981)

#35

Post by yyyk »

jl6 wrote: post #3
diea wrote: post #2

And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200

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…

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.

Re: RFC 791: Internet Protocol (1981)

#36

Post by mindcrime »

formerly_proven wrote: post #19
corty wrote: post #18

Earlier quoted context omitted.

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 conc…

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…

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.

Re: RFC 791: Internet Protocol (1981)

#37

Post by easrng »

mindcrime wrote: post #36
formerly_proven wrote: post #19

Earlier quoted context omitted.

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…

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 m…

I use Spectrum and their IPv6 connectivity drops out relatively frequently, but IPv4 connectivity stays.

Re: RFC 791: Internet Protocol (1981)

#38

Post by saurik »

tenebrisalietum wrote: post #22
throw0101a wrote: post #15

Earlier quoted context omitted.

> 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 tha…

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 wan…

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.)

Re: RFC 791: Internet Protocol (1981)

#39

Post by hansel_der »

adrian_b wrote: post #11
hansel_der wrote: post #7

Earlier quoted context omitted.

> 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 t…

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 addres…

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.

Re: RFC 791: Internet Protocol (1981)

#40

Post by fanf2 »

p1mrx wrote: post #28
fanf2 wrote: post #23

Earlier quoted context omitted.

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 t…

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 mostl…

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.

Post reply on HN