6 ms·

RFC 791: Internet Protocol (1981)

78 points by ewag 5y ago

diea 5y ago
And in the meantime, RFC2460 is more than 20years old... come on guys, adopt IPv6! It's time, and standardized as RFC8200
- jl6 5y ago
  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.
  - formerly_proven 5y ago
    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!
    - trulyrandom 5y ago
      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?
      - corty 5y ago
        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.
        formerly_proven 5y ago
        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.
        mindcrime 5y ago
        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.
    - throw0101a 5y ago
      > 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 https://en.wikipedia.org/wiki/IPv4_shared_address_space I'm waiting for triple-NATing to start occurring.
      - tenebrisalietum 5y ago
        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.
        saurik 5y ago
        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.)
        tenebrisalietum 5y ago
        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.
    - MisterTea 5y ago
      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.
      - formerly_proven 5y ago
        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.
  - yyyk 5y ago
    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.
- znpy 5y ago
  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)
  - adrian_b 5y ago
    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.
    - corty 5y ago
      Most consumer NATs are intentionally configured to be leaky. A commonly used technique is hole punching (https://en.wikipedia.org/wiki/Hole_punching_(networking) 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_Protocol https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc... https://en.wikipedia.org/wiki/Port_Control_Protocol 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.
- bouncycastle 5y ago
  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 https://news.ycombinator.com/item?id=19923519
minroot 5y ago
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 https://tools.ietf.org/pdf/rfc791.pdf
- deleted 5y ago
  [deleted]
- 1vuio0pswjnm7 5y ago
  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.)
palijer 5y ago
Happy birthday!

78 points by ewag 5y ago

diea 5y ago

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

jl6 5y ago
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.
- formerly_proven 5y ago
  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!
  - trulyrandom 5y ago
    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?
    - corty 5y ago
      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.
      - formerly_proven 5y ago
        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.
        mindcrime 5y ago
        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.
  - throw0101a 5y ago
    > 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 https://en.wikipedia.org/wiki/IPv4_shared_address_space I'm waiting for triple-NATing to start occurring.
    - tenebrisalietum 5y ago
      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.
      - saurik 5y ago
        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.)
        tenebrisalietum 5y ago
        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.
  - MisterTea 5y ago
    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.
    - formerly_proven 5y ago
      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.
- yyyk 5y ago
  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.
znpy 5y ago
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)
- adrian_b 5y ago
  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.
  - corty 5y ago
    Most consumer NATs are intentionally configured to be leaky. A commonly used technique is hole punching (https://en.wikipedia.org/wiki/Hole_punching_(networking) 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_Protocol https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc... https://en.wikipedia.org/wiki/Port_Control_Protocol 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.
bouncycastle 5y ago
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 https://news.ycombinator.com/item?id=19923519

minroot 5y ago

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 https://tools.ietf.org/pdf/rfc791.pdf

deleted 5y ago
[deleted]
1vuio0pswjnm7 5y ago
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.)

palijer 5y ago

Happy birthday!