[HN Gopher] Tell HN: IPv6-only still pretty much unusable
       ___________________________________________________________________
        
       Tell HN: IPv6-only still pretty much unusable
        
       Our Hosting provider, Hetzner, has recently started charging for
       public IPv4 addresses - as they should! Those numbers started
       getting expensive. This prompted me to try and set up a new server
       cluster using IPv6 exclusively, and see how far I could get before
       having to give in and purchase an additional v4 address.  The
       experiment ended much sooner than I had anticipated. Some of the
       road blocks I hit along the way:                 - The GitHub API
       and its code load endpoints are not reachable via IPv6, making it
       impossible to download release artefacts from many projects, lots
       of which distribute their software via GitHub exclusively
       (Prometheus for instance).       - The default Ubuntu key servers
       aren't reachable via IPv6, making it difficult to install packages
       from third-party registries, such as Docker or Grafana. While
       debugging, I noticed huge swaths of the GPG infrastructure are
       defunct: There aren't many key servers left at all, and the only
       one I found actually working via IPv6 was pgpkeys.eu.       -
       BitBucket cannot deploy to IPv6 hosts, as pipelines don't support
       IPv6 at all. You can self-host a pipeline runner and connect to it
       via v6, BUT it needs to have a dual stack - otherwise the runner
       won't start.       - Hetzner itself doesn't even provide their own
       API via IPv6 (which we talk to for in-cluster service discovery.
       Oh, the irony.       It seems IPv6 is still not viable, more than a
       decade after launch. Do you use it in production? If so, how? What
       issues did you hit?
        
       Author : 9dev
       Score  : 414 points
       Date   : 2022-12-07 14:51 UTC (8 hours ago)
        
       | tobyhinloopen wrote:
       | Many of the services we work with are just broken with ipv6. Our
       | own services are broken with ipv6.
       | 
       | I just gave up and forced everything in ipv4 mode.
        
       | xlmnxp wrote:
       | Hetzner should provide free CGNAT IPv4 Addresses (IPv4 Gateway)
       | for IPv6-Only VMs
        
         | onli wrote:
         | Just to specify the kind of "should": But they don't, do they?
         | Same with vultr, their ipv6 boxes have no outgoing IPv4
         | connection route.
        
         | manfre wrote:
         | Communal ipv4 is very problematic for certain services due to
         | bad neighbors causing it to be blacklisted.
        
           | detaro wrote:
           | Not for hosting services, but for things like accessing
           | Github.
        
             | jeroenhd wrote:
             | Try accessing the web through TOR and you see why public,
             | shared IP addresses are quite a hassle in practice. Exit
             | nodes don't host anything either, after all.
             | 
             | Actually, that's not even that bad a way to get IPv4 on any
             | IPv6-only host: route it all through TOR!
        
             | vladvasiliu wrote:
             | That's GP's point. Service providers will block the IPs of
             | abusive clients. If those clients are your cg-nat
             | neighbours, you're blocked with them.
        
           | noipv6 wrote:
           | this sounds like a valid argument for deploying ipv6 wherever
           | you can, tbqh
           | 
           | cgnat is only going to get MORE common, globally
        
         | NelsonMinar wrote:
         | A whole lot of ISPs are doing CGNAT for IPv4 now, mostly in
         | Asia. Starlink does it. It's mostly OK but has a lot of
         | drawbacks, particularly IP-based geolocation. (Starlink does
         | not support IPv6 although they seem to be rolling it out this
         | month.)
        
           | [deleted]
        
           | mort96 wrote:
           | Being behind CGNAT has downsides yes, for example being
           | unable to ever host anything; you become relegated to a
           | consumer who's dependent on the big hosting companies to ever
           | have an Internet presence. But geolocation? I don't _want_
           | everyone to be able to get my location! Breaking IP-based
           | geolocation is a benefit of CGNAT, not a drawback.
        
             | NelsonMinar wrote:
             | It's a huge PITA though. I'm near Sacramento but my IP
             | looks like it's in Los Angeles. It screws up a surprising
             | number of things, particularly local TV streaming services.
             | 
             | IP geolocation is a bad idea for lots of reasons.
             | Unfortunately it's also a reality of how services work.
        
           | kps wrote:
           | IP-based geolocation is fundamentally broken. Making it
           | _visibly_ broken in more cases is good.
        
           | noipv6 wrote:
           | 47.57% of observed requests coming out of as14593 is ipv6, as
           | of two days ago:
           | https://twitter.com/noIPv6/status/1600527249282895879
           | 
           | & to be clear, that is CRAZY growth!
           | 
           | edit: that's traffic to monitoring resources, not in general,
           | sorry /facepalm
        
           | heywire wrote:
           | My ISP (Metronet, Ohio, US) uses CGNAT. I've had their
           | service for about 15 months now, and it has been pretty much
           | uneventful. Maybe a handful of times I've gotten a captcha on
           | something, but for the most part, it's just fine. I also
           | don't see thousands of blocked connection attempts a day
           | either, so there is a plus side. I just use Tailscale should
           | I need to access anything at home while I'm away.
        
       | allanrbo wrote:
       | I believe a lot of mobile traffic to services like
       | facebook/netflix/youtube use IPv6. That's a large percentage of
       | internet traffic. And that allows telcos to NAT more customers
       | onto fewer ipv4 addresses.
        
       | n4jm4 wrote:
       | Sounds like IPv6 isn't broken, GitHub and Ubuntu and BitBucket
       | are broken.
        
       | valerij wrote:
       | i for one am also extremely frustrated with the state of ipv6
       | 
       | some time ago i tried to selfhost a personal website and run into
       | all kinds of problems, most frustrating being
       | 
       | - my website not opening when having only AAAA record set (ended
       | up using v4-frontend.netiter.com as a proxy)
       | 
       | - my linux box not handling the ipv6 prefix broadcast from my
       | router and binding to some random address
       | 
       | the latter thing was main reason for frustration as i could find
       | any information how to diagnose and all the message boards/ chat
       | rooms just told me to install random stuff in hope it will then
       | magically work. (i know its a misconfiguration on my linux
       | machine as my windows 10 one can host the website no problem)
        
       | arcade79 wrote:
       | I was thinking about ipv6 the other day. I concluded in my head
       | that adoption was just around 5-10%. Luckily I went to verify
       | that with statistics.
       | 
       | https://www.google.com/intl/en/ipv6/statistics.html
       | 
       | While price of ipv4 addresses are increasing, the world has
       | slowly been adopting ipv6. From the graph above, I'd say we cross
       | over 50% in about 2-3 years time. At some point the "dash" to
       | adopt ipv6 starts, and brave folks will drop support for ipv4.
       | Then it'll probably evaporate between 2030-2035.
        
         | tjoff wrote:
         | That is a very one-sided view of adoption. It ties directly
         | with the rise of mobile and internet in areas that wasn't able
         | to grab IPv4 addresses in time. Such as India. Not sure what
         | France is doing though, maybe something right.
         | 
         | So, from my perspective (which obviously is tied to my
         | location) is that all computers have IPv4 (haven't heard (and
         | I've asked) of a single consumer ISP that offers IPv6) but all
         | mobile phones have IPv6. Whether people in general do most
         | searches on mobile or PC is gonna change that graph
         | dramatically, but won't explain what I would be interested in
         | regarding ipv6 adoption. That is, how much of the world would
         | be broken without IPv4?
         | 
         | And for that, that graph isn't completely useless - but not too
         | far off.
        
           | dieulot wrote:
           | > Not sure what France is doing though, maybe something
           | right.
           | 
           | The telecom regulator (ARCEP) conditioned 5G bands on rolling
           | out IPv6.
        
           | babypuncher wrote:
           | All the big cable and fiber internet providers I've worked
           | with in the US support IPv6, even evil nasty ones like
           | Comcast have supported it for a decade now.
        
             | rekoil wrote:
             | Is it enabled by default on customer equipment?
        
               | FateOfNations wrote:
               | On their leased hardware, it is enabled from what I've
               | seen. And if you are running your own modem and router,
               | you will get IPv6 if you configure your setup to request
               | it (via DHCP). They will even give you a /60 if your DHCP
               | client asks for it.
        
           | noipv6 wrote:
           | okay - how about a few other angles?
           | 
           | https://stats.labs.apnic.net/ipv6/ - per-country, and within
           | a country, per-asn eyeball statistics, collected from online
           | ads - not just mobile!
           | 
           | https://www.facebook.com/ipv6/?tab=ipv6_country - per-
           | country, albeit with a mobile-heavier bias (as you hint)
           | 
           | https://www.akamai.com/internet-station/cyber-
           | attacks/state-... - collected from their content delivery
           | network - tends to show lower adoption than the other metrics
           | 
           | i would point out that "all mobile phones have IPv6" isn't
           | true globally, but it is the reality in some countries, yes.
        
             | MrRadar wrote:
             | Ugh, Centurylink. Their networks, both DSL and Fiber,
             | support IPv6 but you need to go into the router config and
             | explicitly enable it which is why they show up as 0.5% IPv6
             | supported in that first link despite every other top-10 US
             | ISP having at least 50%. I've enabled v6 on my home
             | connections with them on both DSL and fiber and I've had
             | absolutely no problems with it. I wish they would enable it
             | by default with their consumer network equipment.
        
             | tjoff wrote:
             | Neat, very different results. But still looking at it from
             | the wrong direction?
             | 
             | That is, ipv6 for clients. But I'm more interested in
             | servers, because that is what would affect me if I don't
             | have IPv4. Such as the experiences described by OP in this
             | thread.
        
               | noipv6 wrote:
               | ipv6-only web sites are borderline nonexistant, because
               | no one who needs to maintain a profit dares to cut off a
               | revenue stream from legacy ip only users (yet).
               | 
               | the most exhaustive list thus far is https://sites.ip-
               | update.net/ afaik
        
               | tjoff wrote:
               | I'm not asking for ipv6-only, but ipv4-only.
               | 
               | Those are the ones blocking adoption for me, as an end
               | user.
        
               | noipv6 wrote:
               | derp yes
               | 
               | https://whynoipv6.com/
        
           | sp332 wrote:
           | Comcast added IPv6 ages ago. Time Warner and AT&T (FTTH, not
           | just mobile internet) support it now as well.
        
         | bombcar wrote:
         | I'd love for some way to measure how much of my network's
         | traffic outbound and inbound is IPv6. I assume there's some way
         | to "count" it on the router, but Mikrotik doesn't seem to
         | expose it directly.
        
           | Melatonic wrote:
           | In addition to NextDNS I have been running a firewall app on
           | my android phone (which also points to NextDNS) and shows all
           | this. Good easy way to get started. ReThinkDNS is the app I
           | am currently using because it integrates some block lists
           | well but there is also a more serious Android firewall app I
           | may switch to.
        
           | jrmg wrote:
           | I don't know if this corresponds to traffic, but my local DNS
           | server shows that it's returning more AAAA results that A
           | results (_just_) nowadays.
           | 
           | This is a home cable connection in the Bay Area.
        
           | yusyusyus wrote:
           | iirc mikrotik supports netflow. that's how i account for
           | proto balance. FWIW, owing to the nature of residential
           | traffic, I've typically seen high (60-70% of traffic) as v6.
        
             | bombcar wrote:
             | Yeah, if the stream platform CDNs support IPv6 (Do they? is
             | there a site that lists it?) then the vast majority of
             | residential traffic will be IPv6.
        
               | lzaaz wrote:
               | This is exactly why this isn't a good way to measure ipv6
               | adoption. For example, youtube supports ipv6; if you
               | spend all day watching youtube, 80%+ of your traffic will
               | be ipv6.
        
           | SamuelAdams wrote:
           | PiHole is actually pretty great for this. I set up some
           | firewall rules in OpnSense to force all devices to use PiHole
           | as a DNS server. Then log all queries.
           | 
           | You can see which clients are using ipv6 and how many queries
           | there are. I would estimate that about 60% of iPhone traffic
           | in my household (by far the busiest devices) is ipv6. We
           | usually use big sites though like Reddit, twitter, google,
           | etc.
           | 
           | And then there's the Rokus that don't support ipv6 at all.
           | Considering how cheap they were it doesn't really surprise
           | me.
        
         | mort96 wrote:
         | > At some point the "dash" to adopt ipv6 starts, and brave
         | folks will drop support for ipv4.
         | 
         | I wouldn't be sure about that. I don't see any "dash" to
         | support v6 in our future, when the option to just keep working
         | around issues with v4 is so much easier and cheaper in the
         | moment. Really, what does _anyone_ have to gain by switching to
         | v6?
        
           | Latty wrote:
           | The thing is, it's not v6 or v4, it's v6, v4 with a price
           | premium, or v4 with CGNAT.
           | 
           | CGNAT sucks. Stuff blocks you because you get lumped in with
           | other users. You can't take inbound connections. Average
           | users don't know that, but they get annoyed with side
           | effects. Not being able to play multiplayer stuff or it being
           | slow/high latency because of no inbound connection. Having to
           | do extra CAPTCHAs, being straight out blocked, etc...
           | 
           | Price and annoyance are absolutely things people want to
           | avoid.
           | 
           | I guarantee you at some point, some ISP is going to realise
           | they can market themselves as _the gamer ISP_ and sell IPv6
           | as _the_ option for pro gamers to ensure the lowest latency
           | in their games. CGNAT will be the congested roads, IPv6 the
           | open motorway. (To be clear, it obviously isn 't that simple,
           | but I'd put money on that's how they'll sell it.)
        
           | noipv6 wrote:
           | > I don't see any "dash" to support v6 in our future, when
           | the option to just keep working around issues with v4 is so
           | much easier and cheaper in the moment.
           | 
           | 30-40% global adoption in ~10 years may or may not be a
           | "dash", but it's also not nothing.
           | 
           | "easier and cheaper" is very much not the case at larger
           | scale. legacy ip space is only growing more expensive, &
           | cgnat platforms are not cheap. even if a carrier HAS TO
           | deploy cgnat, deploying ipv6 first means you don't need to
           | buy cgnat capacity for any v6-native traffic (which is a non
           | trivial volume)
           | 
           | > Really, what does anyone have to gain by switching to v6?
           | 
           | the above, & also a future-proofed, infinitely scalable
           | network. any org's that do alot of m&a don't have to play as
           | many stupid rfc1918 integration games.
           | 
           | if you don't deal w/ scale, yea, hard to see the benefits.
           | fair.
        
             | mort96 wrote:
             | > 30-40% global adoption in ~10 years may or may not be a
             | "dash", but it's also not nothing.
             | 
             | Still nowhere close to being remotely unusable after soon
             | 30 years is very very close to nothing.
             | 
             | Regarding benefits: Amazon, Azure and all the other major
             | VPS companies has a lot to gain from IP addresses being
             | expensive, since it makes it almost impossible for new
             | players to enter the market. ISPs may pay for CGNAT in
             | terms of infrastructure and complexity, but they save in
             | support and abuse mitigation cost by making it impossible
             | for normal people to host their own stuff, they save in
             | support cost by not dealing with customers' broken products
             | which get confused by IPv6, and they gain financially from
             | charging a ton for "pro"/"enterprise" non-CGNAT
             | connections.
             | 
             | And for any kind of web service, supporting IPv6 is
             | obviously just a net negative, since you have to deal with
             | both v4 and v6 rather than just v4.
             | 
             | So I suppose I'm saying, sure, there are minor things to
             | gain from v6, but it's not clear that they outweigh the
             | (opportunity) cost of v6 for anyone, and for large sectors
             | it's simply a cost with no upside.
             | 
             | I don't see a rush to support v6... ever. We'll keep
             | growing steadily but slowly for a while, then adoption will
             | taper off.
             | 
             | But hey, I may be wrong! I'd certainly be happy if you were
             | right. The minuscule amount of progress across almost 30
             | years doesn't instill confidence though.
        
       | andix wrote:
       | Maybe it's time to declare IPv6 as failed and find something new?
        
       | redox99 wrote:
       | IPv6 has been one of the biggest failures in the last couple of
       | decades.
       | 
       | And I don't mean adoption, I mean the standard itself.
       | 
       | If IPv6 were IPv4 with more octets, then we would all have been
       | using it for like a decade.
       | 
       | Yes, I understand it would still require some breaking changes,
       | but it would have been a million times easier to upgrade, as it
       | would be a kind of superset of IPv4 (1.2.3.4 can be referred as
       | 0.0.0.0.1.2.3.4).
       | 
       | Not having two sets of firewall rules and two sets of everything.
       | I always disable IPv6 because it can bite you so hard when you
       | don't realize that you are wide open to IPv6 connections because
       | of different firewalls.
       | 
       | Edit: To make everything a bit clearer, the idea with this
       | "ipv4+" is that you don't need the complexity of running both
       | ipv4 and ipv6 as you do now.
       | 
       | And regarding compatibility, with ipv4+ if you have a
       | 0.0.0.0.x.x.x.x ip address you would be able to talk to both
       | ipv4+ aware and legacy ipv4 devices natively without any
       | tunneling (because you also own the legacy, non quad 0 ip
       | address). If you don't have such "quad 0 ip" (you are
       | 1.1.1.1.x.x.x.x), only ipv4+ aware devices would be able to to
       | connect to you, and for you to connect to non ipv4+ aware devices
       | you would need either tunneling, or having a secondary, cgnat,
       | "quad 0 ip".
        
         | zhoujianfu wrote:
         | I always thought to start they should have just allowed each
         | octet two-ish more bits, so you could have 999.999.999.999. I
         | know it's the hackiest of all hacks, but it sure would have
         | been an easy upgrade from the software perspective. And it
         | would have given about a 256x increase in the number of ips.
         | Which I kinda think actually might have served us for a long
         | time.
        
         | detaro wrote:
         | > _(1.2.3.4 can be referred as 0.0.0.0.1.2.3.4)._
         | 
         | Which would need translation support at the edges between
         | devices speaking only old-IPv4 and the superset-IPv4. Just as
         | is done with IPv6.
        
           | redox99 wrote:
           | Obviously hardware would need to be upgraded. But it is much
           | much simpler, and you don't have separate configurations for
           | Ipv4+ and ipv4.
        
           | jedberg wrote:
           | Except that it would be a small incremental change instead of
           | a whole second stack.
        
         | kevin_thibedeau wrote:
         | The IPv4 dotted quad format carries a lot of baggage. You also
         | have to handle forms with two numeric fields with a mixture of
         | 8, 16, and 24-bit numbers and implicit zero octets. Support for
         | the full syntax is sporadic. IPv6 deliberately uses a new text
         | encoding to make a clean break.
        
         | rnhmjoj wrote:
         | > If IPv6 were IPv4 with more octets, then we would all have
         | been using it for like a decade.
         | 
         | I don't really think so: it woulds still be completely backward
         | incompatible and still require replacing a lot of costly
         | network equipment. I think that's the main reason why large
         | ISPs and enterprises have been postponing the upgrade since
         | forever but operating systems, smartphones and other new
         | devices didn't really have a problem with it.
        
           | redox99 wrote:
           | It's been decades. The vast majority of network equipment
           | already has been replaced multiple times since IPv6 became a
           | thing that people "understood" we would switch in the future.
           | 
           | The difference is that instead of their ipv6 being broken,
           | partial, or correct but non functioning because it needs
           | additional configuration, it would properly work and support
           | with the much simpler "ipv4+"
        
             | rnhmjoj wrote:
             | But IPv4+ is incompatible, so it requires to maintain two
             | network stacks until reasonably everything has moved over
             | to it. You need to duplicate the configuration for DNS,
             | routing, firewalls etc., exactly as for dual stack IPv6. I
             | don't really see a difference.
        
               | andix wrote:
               | IPv4+ would be backwards compatible as long as the first
               | 4 bytes are zero. So you could just replace the existing
               | ipv4 stack.
               | 
               | Ipv6 is not backwards compatible at all.
        
               | yyyk wrote:
               | IPv6 is a slightly different model, different enough that
               | you can't just copy the configuration from IPv4, and that
               | adds a significant implementation burden. If IPv4+ had
               | been created instead, we'd probably all be already using
               | it.
               | 
               | That said, it's obviously way too late to go that
               | direction. The only successor to IPv4 is IPv6. Choosing
               | the wrong model just made sure we'd have to go dual-stack
               | for a loong time.
        
               | jedberg wrote:
               | Imagine I own a company and I already have a bunch of
               | IP4. I upgrade my network equipment to IP4+, and then
               | keep all my routing and firewall configs. Everything just
               | works the same as before. Now I want to access IP4+, so I
               | add a route entry for all the IPs above 255.255.255.255.
               | In fact, if that entry is just "send everything to my
               | upstream" it might already work!
               | 
               | Now I want to add some new resources but I'm out of IPv4
               | space. So I get some IP4+ space and a new host with a new
               | firewall rule for the new octet and a DNS entry. Of
               | course only other people on IP4+ can reach it, so I use
               | it for my internal tools since I know all of my clients
               | support IP4+.
               | 
               | Then I want to use it for a public service, so I add a
               | dual DNS entry of 0.0.0.0.1.2.3.4 and 1.2.3.4. IPv4
               | clients get 1.2.3.4 and IP4+ clients get 0.0.0.0.1.2.3.4.
               | Now I can start collecting data on how many people
               | support IP4+. When it gets high enough, I can shut off
               | the v4 address and move it to IP4+ only.
               | 
               | It would make the transition just soooo much easier,
               | because the changes are much more incremental. I don't
               | have to set up a whole new dual stack. I can just make a
               | few dual entries.
        
               | rnhmjoj wrote:
               | If you really wanted you to could keep you old addressing
               | scheme in IPv6 (arbitrary IPv4 addresses can be embedded
               | into IPv6), you can disregard all best IPv6 practices
               | about subnetting and do everything like you did for IPv4,
               | DHCP and all, heck even NAT. The problem is that as soon
               | as you're turning it on you need to maintain two sets of
               | routing and firewall configs, even if they were
               | identical.
               | 
               | Also you need _proper_ support from all those lazy
               | vendors (both hardware and software) that did the
               | absolutely minimal amount of work to advertise their
               | products as IPv6 ready when it fact the support ranges
               | from subpar to practical unusable.
               | 
               | As soon as you make a one bit incompatible change to the
               | protocol routers aren't able to communicate anymore: it's
               | the same situation again. It doesn't matter how similar
               | the two protocols are, they're incompatible.
        
               | throw0101a wrote:
               | > _Imagine I own a company and I already have a bunch of
               | IP4. I upgrade my network equipment to IP4+, and then
               | keep all my routing and firewall configs. Everything just
               | works the same as before. Now I want to access IP4+, so I
               | add a route entry for all the IPs above 255.255.255.255._
               | 
               | It does not. Because 255.255.255.255 only covers 32 bits
               | and "IP4+" is >32 bits. You'd still have to touch every
               | rule to to tweak the mask.
               | 
               | Oh, and your IP4+ idea already exists:
               | 
               | > _Addresses in this group consist of an 80-bit prefix of
               | zeros, the next 16 bits are ones, and the remaining,
               | least-significant 32 bits contain the IPv4 address. For
               | example, ::ffff:192.0.2.128 represents the IPv4 address
               | 192.0.2.128. A previous format, called "IPv4-compatible
               | IPv6 address", was ::192.0.2.128; however, this method is
               | deprecated.[61]_
               | 
               | * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_add
               | resse...
               | 
               | * https://datatracker.ietf.org/doc/html/rfc4291#section-2
               | -5-5
               | 
               | You _still_ need to upgrade bit of networking kit between
               | the source and destination to understand  "IP4+", and
               | this (lack of) upgrading and enabling is what is
               | hampering deployment.
               | 
               | What makes you think that companies would have been
               | willing to make the effort to deploy "IP4+" any more than
               | IPv6?
        
               | convolvatron wrote:
               | I still don't understand why they shifted from 0:: to
               | ffff::
               | 
               | but point stands, ipv6 is exactly ipv4+, except yes, they
               | did redo arp. I don't think its really that much
               | better...but really? that's what turns something from
               | great into awful?
        
               | jedberg wrote:
               | > You'd still have to touch every rule to to tweak the
               | mask.
               | 
               | No you wouldn't. 0.0.0.0.1.0.0.0/40 and 1.0.0.0/8 are the
               | same thing. If the rule says 1.0.0.0/8 then the router
               | converts it to 0.0.0.0.1.0.0.0/40. If you happen to have
               | 1/8 as your rule, then an easy fix is to say ip4+
               | translates shorthand rules at ipv4 if the mask is under
               | /32.
               | 
               | > What makes you think that companies would have been
               | willing to make the effort to deploy "IP4+" any more than
               | IPv6?
               | 
               | Because when they went to upgrade their router, as they
               | often do every decade, it would just support IP4+ with no
               | config changes on their end. They would pull their config
               | from their old router and it would just work.
               | 
               | Then they would discover they had IP4+ support and maybe
               | start using it.
               | 
               | The reason it is easier is because it's a small
               | incremental change.
        
               | pantalaimon wrote:
               | Do addresses have a variable length in your IPv4+ header?
        
               | jeroenhd wrote:
               | > No you wouldn't. 0.0.0.0.1.0.0.0/40 and 1.0.0.0/8 are
               | the same thing.
               | 
               | I don't see why the CIDR would make a direct difference.
               | Whether it's converting 1.0.0.0/8 to 0.0.0.0.1.0.0.0/40
               | or 2002:c000:0204::1.0.0.0/96 doesn't seem to matter to
               | me. The only difference I can think of is local networks
               | (10/8, 192.168/16, 172.16/12) but your suggestion would
               | fail in the same way.
               | 
               | Several compatibility systems for IPv6 exist. 6to4 is the
               | most common one I've seen. It all works on a technical
               | level until DNS gets involved.
               | 
               | > Then they would discover they had IP4+ support and
               | maybe start using it.
               | 
               | If your business network is managed by "hey, this feature
               | exists, let's see what happens if we turn it on" then
               | your network admin needs to be more professional.
        
               | jedberg wrote:
               | > If your business network is managed by "hey, this
               | feature exists, let's see what happens if we turn it on"
               | then your network admin needs to be more professional.
               | 
               | I think this is why you don't understand how IP4+ would
               | be easier. 99% of companies make their "IT guy" manage
               | the network. They aren't network professionals. They are
               | mostly desktop professionals who also get forced to
               | manage the network and firewall. Same with most schools
               | -- they can't afford to hire network professionals.
               | Sometimes they get lucky and someone is excited about
               | learning networking, but that's not true in most cases.
               | 
               | If they already have a bunch of IPv4 rules that some
               | contractor wrote once, and they have a vague understand
               | of how those rules work and why, they don't want to learn
               | a new scheme or run 6to4 or anything else. They just want
               | it to work by copying the old config and then maybe if
               | they have time they can explore the new features of their
               | new equipment.
        
               | jeroenhd wrote:
               | If it's just "The IT guy", then IPv6 will work out of the
               | box for outgoing traffic and will block all incoming
               | traffic. This is why almost half of the USA is using IPv6
               | right now, it's just turned on by default.
               | 
               | Hosting stuff is harder, but it's also that different.
               | Theoretically, you can NAT IPv6 traffic to an IPv4 server
               | inside your network no problem, but it's a pain and
               | nobody really needs it anyway, so it's not widely used.
        
               | jedberg wrote:
               | I think you're missing the point. You're a network
               | engineer and know what you are doing. Most people aren't.
               | 
               | IP4+ would be easier because it's more incremental and
               | less change than IPv6.
               | 
               | Yes, there exists solutions to all the problems that IP4+
               | would solve, but the point is backwards compatibility and
               | incremental change is always easier than doing something
               | new.
        
               | jeroenhd wrote:
               | But, correct me if I'm wrong, IP+ doesn't do anything
               | differently from IPv6, except that it changed the 6to4
               | prefix?
               | 
               | Host 1.2.3.4.5.6.7.8 still can't communicate with a
               | "legacy" host 4.5.6.7 without some kind of bidirectional
               | translation mechanism. Just prepending 0.0.0.0 to an
               | address (or 2002:c000:0204, for that matter) doesn't fix
               | the problem.
        
               | jcranmer wrote:
               | The evidence at this point I think refutes your argument.
               | It's been the case for a while now that basically all the
               | hardware, all the networking stacks, all the major
               | libraries and software supports IPv6. So the reason
               | people haven't switched to IPv6 as quickly is because
               | there's all sorts of hidden IPv4 assumptions that take
               | significant effort and energy to get rid of--and there's
               | relatively little resources being devoted to rooting
               | those out.
               | 
               | The kinds of things I'm talking about are places where an
               | IP address is stored in a uint32_t in the middle of your
               | core business app somewhere. Or maybe you've got some log
               | sniffing that only looks for four dotted octets and can't
               | pick an IPv6 address. Those are the sorts of things that
               | if you move to _any_ system that 's not IPv4, it's just
               | not going to work period. And you're often not going to
               | discover that you have these issues until you try forcing
               | things to use not-IPv4.
               | 
               | A migration I've been working on--admittedly not in
               | networking--has been LLVM's opaque pointer migration, and
               | the vast majority of the time has been spent not figuring
               | out how to get rid of every
               | "pointer_type->getPointerElementType()" call, but in
               | quashing all of the assumptions like "this input operand
               | has to be a bitcast of a global variable" that is
               | violated by the pointer migration. I have no reason to
               | expect that the IPv4-to-IPv6 migration is not similar, in
               | that most of the effort is going to be spent on code that
               | you didn't think would assume it is using IPv4.
        
               | [deleted]
        
         | codegeek wrote:
         | I always joke with "We figured out how to move from Python 2 to
         | 3 but we still cannot figure out how to do IPv6" :). What a
         | catastrophic failure it has been. Should we just stop using it
         | altogether and retire or are there people still advocating ?
        
           | ipython wrote:
           | Yes, people are using ipv6 for real deployments. See any
           | large scale mobile network deployment. Funny thing is most
           | people never realize because it all just works...
        
         | est31 wrote:
         | One of the ideas of ipv6 was to reduce routing tables, those
         | tables that backbone providers have to keep in memory and look
         | up for incoming traffic. With ipv4's fragmented allocation
         | scheme, these routing tables are huge. With ipv6, even huge
         | companies like amazon only have a couple of global allocations.
         | A "ipv4 with more octets" scheme would have kept that
         | fragmentation around.
         | 
         | That being said, Amazon currently has 2880 ipv4 allocations and
         | 946 ipv6 allocations... not much gained I guess? :p
         | https://asnlookup.com/asn/AS16509/
         | 
         | Also, there are definitely some horrible ipv6 warts, like that
         | the only standard for local ipv6 addresses forces you to adopt
         | a scheme where your local address is horribly long, for the
         | sake of global uniqueness, which is something that most people
         | don't really need.
        
           | justsomehnguy wrote:
           | > Amazon currently has 2880 ipv4 allocations and 946 ipv6
           | allocations... not much gained I guess?
           | 
           | Whole IPv4 address space is 4294967296 addresses.
           | 
           | A single /48 is 1,208,925,819,614,629,174,706,176.
           | 
           | And 2804:800::/32 is 79,228,162,514,264,337,593,543,950,336.
        
             | ipython wrote:
             | Gp comment refers to the number of routing table entries,
             | not total number of addressable ips.
             | 
             | Ideally the number of ipv6 allocations should be close to 1
             | rather than close to 1000.
        
           | viraptor wrote:
           | > where your local address is horribly long, for the sake of
           | global uniqueness, which is something that most people don't
           | really need
           | 
           | Apart from debugging where you can copy-paste anyway, does it
           | matter? I've got a few services on the local network and over
           | zerotier that all talk IPv6. In the last 3 years or so I've
           | never used an ipv6 address directly. There's enough DNS and
           | discovery protocols that I never needed to.
        
             | zahllos wrote:
             | Plus if you're using enough IPv4 addresses it is going to
             | be the same problem anyway. I can barely keep track of what
             | I've assigned everything to in just a /24 so I have local
             | DNS and I don't need to.
        
           | tlb wrote:
           | I'm not up to date, but when I knew about this stuff the cost
           | of memory for routing tables was only a tiny, tiny fraction
           | of the cost of a network. Most of the cost is burying and
           | maintaining fiber.
           | 
           | So unless something big has changed, it seems like a terrible
           | choice to twist the whole system into uselessness to try to
           | save a small amount of RAM cost.
        
             | cranekam wrote:
             | According to this Stack Exchange post from last year a full
             | IPv4 routing table requires on the order of a few hundred
             | MBs of RAM. This is indeed a tiny fraction of the cost of
             | maintaining the global internet infrastructure.
             | 
             | https://networkengineering.stackexchange.com/questions/7656
             | 2...
        
               | bauruine wrote:
               | The problem is that the routers that have to hold the
               | routing table can only handle a limited number of routes.
               | There is a good article from APNIC about the topic.
               | 
               | https://blog.apnic.net/2021/03/03/what-will-happen-when-
               | the-...
        
               | pifm_guy wrote:
               | Said routers could be redesigned...
               | 
               | And besides, there is no need to keep the whole routing
               | table in RAM. Instead all that's necessary is a single
               | integer per route representing which port packets to each
               | route needs to be sent down. So even for a large router
               | with 64 ports, the whole routing table fits inside 1
               | megabyte.
        
             | Dagger2 wrote:
             | It's not "twisted into uselessness"... the reduction in
             | routing table size comes from the large address space. No
             | twisting was needed.
             | 
             | Also, the routing tables we're talking about here need to
             | be stored in TCAM. Content-addressed memory is a lot more
             | expensive than regular DRAM.
        
           | Sesse__ wrote:
           | > One of the ideas of ipv6 was to reduce routing tables
           | 
           | That idea was abandoned about 20 years ago. One fairly
           | quickly discovered that hierarchical routing does not work
           | well in the real Internet, where redundancy is done on the IP
           | level with everybody and their dog having provider-indepent
           | IP space.
           | 
           | > like that the only standard for local ipv6 addresses
           | 
           | Which one is the only standard? Link-local, site-local, ULA,
           | or using a non-routed netblock with or without DHCPv6 (or
           | RA)?
        
         | spookthesunset wrote:
         | It's the firewall rules that always creep me out. The nice
         | thing about NAT is open ports on your internal network are
         | hidden to the outside world by default. You have to think about
         | which ports you want the NAT gateway to forward.
         | 
         | With IPv6 the entire network is reachable outside by default.
         | Granted I assume you can probably create a default DENY rule
         | for inbound traffic and selectively open ports up as
         | exceptions. Right?
        
           | marcosdumay wrote:
           | > The nice thing about NAT is open ports on your internal
           | network are hidden to the outside world by default.
           | 
           | That is usually not true. NAT punching is a thing for decades
           | now.
        
             | pflanze wrote:
             | - NAT punching does require cooperation of programs on the
             | protected machines, though, no? How is it different from
             | them inviting traffic in any other way (like, requesting a
             | page via https from an infected server could hijack the
             | client on the protected machine if the client has security
             | holes in the right places; the https client is willing to
             | get traffic here, just as some VoIP program is willing to
             | receive a call)?
             | 
             | - And is it any different from a stateful firewall on IPv6?
        
           | WastingMyTime89 wrote:
           | My own ISP provided router is by default setup to deny all
           | inbound traffic on IPv6. I'm surprised it's not the default
           | everywhere.
        
             | noipv6 wrote:
             | it's the default behaviour by most cpe, correct
             | 
             | any exceptions to this should be roasted (my twitter dm's
             | are open)
        
             | Semaphor wrote:
             | My ISP doesn't support IPv6 at all, unless I want to
             | voluntarily go behind a CGNAT.
        
           | Quillbert182 wrote:
           | I just started University, and as a result I have had my
           | first experience of Internet without NAT. The firewall rules
           | provided are simply On or Off, which has been very strange to
           | me, and it doesn't seem all that secure.
        
           | justusthane wrote:
           | > Granted I assume you can probably create a default DENY
           | rule for inbound traffic and selectively open ports up as
           | exceptions. Right?
           | 
           | Sure, of course. That's how firewalls work for IPv4 as well--
           | you have an implicit deny rule at the end, and then allow
           | rules come before it.
        
           | justsomehnguy wrote:
           | > With IPv6 the entire network is reachable outside by
           | default
           | 
           | Only, and only, if you configured your router that way.
           | 
           | In both cases, it's absolutely the same:
           | IPv4 -> allowed NAT ports -> NAT network -> Everything else
           | is dropped/denied                  IPv4 -> allowed ports ->
           | directly routed IPv4 network -> Everything else is
           | dropped/denied                  IPv6 -> allowed ports ->
           | directly routed IPv6 network -> Everything else is
           | dropped/denied
           | 
           | See?
           | 
           | Of course if you are on someone's else network (typical for
           | hosting when you aren't provided with your own v6 subnet,
           | instead you have a bunch of addresses) then you should
           | configure firewall on each your machine... which is what you
           | need to do anyway?
        
           | crest wrote:
           | > It's the firewall rules that always creep me out. The nice
           | thing about NAT is open ports on your internal network are
           | hidden to the outside world by default. You have to think
           | about which ports you want the NAT gateway to forward.
           | 
           | Have you never had more than a handful of IPv4 addresses?
           | IPv6 works the same in this regard as a router IPv4 network
           | e.g. universities, large/old enterprises etc. NAT started as
           | a workaround to make the available public address space last
           | longer.
           | 
           | The address (and port) translation wasn't intended as a
           | security feature on its own. These days lots of protocols
           | automatically deal with NAT and mostly manage to establish
           | bidirectional communication over UDP or TCP through NATs. I
           | rather deal with stateful firewalls and public IPv6 addresses
           | end to end instead of gluing the segments of flows between
           | IPv4 translators back together.
        
           | anilakar wrote:
           | RFC7084 says a NAT-like stateful firewall mechanism should be
           | enabled by default on customer IPv6 routers.
        
           | vel0city wrote:
           | > With IPv6 the entire network is reachable outside by
           | default.
           | 
           | The entire network might be _routable_ , but it often isn't
           | _reachable_. My router had a default deny rule, so everything
           | in my network for sure wasn 't reachable by default despite
           | having IPv6 addressing.
           | 
           | If anything, I like firewalling in IPv6 far better than
           | dealing with NATs. Just imagine having multiple boxes you'd
           | like to reach by SSH or HTTPS from the outside. With NAT, you
           | can only run one on a standard port. With IPv6, there's no
           | need to NAT, everything can just use one of their _many_
           | public IPv6 addresses, and then I can firewall to allow
           | traffic to each of those boxes at the standard ports.
           | 
           | In fact, this gets even cooler. I can then have multiple
           | services all bound to different IP addresses and have
           | different firewall rules related to each of those services.
           | There's so much more possible using IPv6 that you just
           | practically can't do in IPv4, unless you just happened to
           | have a /8 assigned to you back in the day.
           | 
           | Think about this: every device in my home network gets more
           | IP addresses assigned to it than there are IP addresses in
           | IPv4. I can have every container on my cluster have its own
           | publicly routable IPv6 address, every application I run could
           | theoretically have its own address and have its own network
           | rules applied. And then I can look at my network edge and
           | immediately identify any and all traffic flowing through that
           | edge.
           | 
           | I can't wait until IPv4 is dead and I never have to deal with
           | NAT issues again.
        
           | gertrunde wrote:
           | No.... Absolutely no...
           | 
           | NAT is absolutely not in any way a substitute for an actual
           | firewall, despite the side effect of 'blocking' ports.
           | 
           | And how is "You have to think about which ports you want the
           | NAT gateway to forward." any different from thinking about
           | firewall rules?
           | 
           | And most consumer CPE devices (i.e. 'router' etc) are
           | perfectly capable of running a firewall, and often do.
           | 
           | And any firewall that doesn't drop inbound traffic by default
           | is not really much use at all.
           | 
           | And lastly, if you want you can still do NAT66 if you really
           | must, or IPv6 network prefix translation, which is a slightly
           | improved version.
        
             | lzaaz wrote:
             | It is a substitute to an actual firewall because I don't
             | need a firewall since NAT makes all of my listening ports
             | unavailable to my WAN.
        
               | Dagger2 wrote:
               | This is straight up untrue. The only thing NAT does is
               | change the apparent source address of outbound
               | connections. Inbound connections aren't outbound
               | connections, so it does nothing to them.
               | 
               | NAT is not a substitute for a firewall.
        
               | noipv6 wrote:
               | those of us who want to have the same port on different
               | computers available to the internet might see that as a
               | bad thing
        
               | staringback wrote:
               | Oh you don't need a firewall then? I guess accessing a
               | routers web interface from the WAN is a-okay
        
               | lzaaz wrote:
               | My router's httpd listens on the LAN not the WAN unless I
               | tell it to. This is unrelated to what I said.
        
               | jraph wrote:
               | My shitty cable modem which is also a router does not
               | expose its web interface to the world by default.
               | 
               | I don't understand why you'd need a firewall if
               | 
               | - you trust devices on your network (yes, big if, but
               | even then: the only reachable ports of a machine from the
               | outside are those explicitly open to the outside, most
               | stuff listens to 127.0.0.1 anyway)
               | 
               | - you only configure your NAT to forward ports you would
               | open on your firewall
        
               | sph wrote:
               | My shitty router also firewalls incoming IPv6 connections
               | by default, unless I manually allow them per-device, so I
               | don't get your point.
        
               | jraph wrote:
               | My point is lzaaz's one
               | https://news.ycombinator.com/item?id=33897568
               | 
               | I didn't think of my cable modem as a firewall. Maybe
               | technically it has one to provide the feature of blocking
               | access to its web interface from the world, or maybe it
               | just listens to the right network. I don't know, but for
               | all intent and purposes, setting up a firewall myself
               | does not seem necessary.
               | 
               | To be fair, I was also a bit annoyed by staringback's
               | phrasing.
        
               | staringback wrote:
        
               | jraph wrote:
               | What's with the attacks??
               | 
               | I make sure what I build supports IPv6 (and I'll use
               | tunnels if it's what it takes) but I can't make the only
               | cable ISP available at my place support IPv6. I wish it
               | did. I wish I didn't have to use its garbage hardware.
        
               | vel0city wrote:
               | Depending on the NAT implementation this can be
               | incredibly naive. Many home routers will send ANY traffic
               | incoming on a port to the NAT'd IP address, even if the
               | sources don't line up.
               | 
               | So say Alice is behind a crappy NAT and wants to talk to
               | Bob. Alice's router opens a port on its edge, lets say
               | 1234, and sends traffic to Bob on port 80.
               | 
               | Let's say Charles knows Alice's IP address. Charles
               | starts spamming Alice's router, eventually hitting port
               | 1234 with bad data.
               | 
               | Alice's router is dumb. It sees traffic on port 1234,
               | checks its NAT table, and sees that data is supposed to
               | go to Alice. It happily rewrites that packet and passes
               | it along to Alice. Now Alice is getting traffic from Bob
               | *and* Charles. Uh oh!
               | 
               | Many game consoles are explicitly _designed_ around this
               | bad, broken behavior. You 'll open a port to the
               | matchmaking server and then the matchmaking server will
               | tell people to connect to that IP address and port
               | combination. Crappy home routers will happily route that
               | data through its NAT configuration to the console despite
               | the console never explicitly opening up traffic to those
               | other parties. This is why some game consoles will
               | complain about closed NAT versus open NAT.
        
               | lzaaz wrote:
               | That's like saying that a bad firewall implementation
               | leaks like a sieve. This is not what I was talking about.
        
               | lazide wrote:
               | Any router running a poor NAT implementation (aka most of
               | them) essentially has a built in firewall bypass for the
               | right attacker.
               | 
               | A naive NAT implementation can allow an attacker to
               | bypass the firewall.
        
               | jraph wrote:
               | Curious, could you expand on this?
        
               | vel0city wrote:
               | I gave an example just a few comments above this. Alice
               | never wanted Charles' traffic, the firewall should not
               | have let it through. But because the NAT is dumb, and the
               | firewall rules are often tied to the NAT on these crappy
               | home routers, it's allowed. So now because Alice wanted
               | to talk to Bob, she opened a port to the world that she
               | never wanted opened as wide.
        
               | jraph wrote:
               | Thanks! (you added this afterwards, right? Or it's just
               | me being tired and skipping this)
        
             | spiritplumber wrote:
             | I use an old Parallax Propeller server as my DMZ, with
             | instructions to log everything and answer "OK" to
             | everything. It's funny what people try to do to it.
        
               | ddalex wrote:
               | Why don't you write a blog post about this? I'm
               | interested to see what will go on
        
             | devnullbrain wrote:
             | >NAT is absolutely not in any way a substitute for an
             | actual firewall, despite the side effect of 'blocking'
             | ports.
             | 
             | This is one of those infosec tenets that is technically
             | true but functionally unhelpful. Like correct-horse-
             | battery-stable debates.
             | 
             | The claim is that IPv4 + NAT + bad firewall is better than
             | IPv6 + bad firewall.
             | 
             | Yes, both are insufficient and inferior to a good firewall
             | - but how confident are you that you never interact with a
             | bad firewall?
        
               | derefr wrote:
               | What makes you think that, for critical systems, "IPv4 +
               | NAT + bad firewall" is the default IPv4 deployment
               | paradigm, rather than "IPV4 + bad firewall"?
               | 
               | Sure, big IaaS providers like AWS put you in a VPC by
               | default. But most servers on the net are not hosted in an
               | IaaS; they're hosted using a VPS or bare-metal hosting
               | provider, or just coloed in a DC by their owner. And in
               | all those cases, what that kind of deployment gets you,
               | is a public IPv4 per VM/machine, that anyone on the
               | Internet can march right up and talk to, where it's the
               | responsibility of the machine itself to reject incoming
               | packets (i.e. at the OS level with a kernel firewall.)
               | 
               | NAT on IPv4 is only really a default assumption for
               | residential networks. Anywhere else, it's pretty much
               | like the movie WarGames: even the mainframe has a phone
               | number you can call. Staying on IPv4 isn't making anyone
               | safe.
        
               | 293984j29384 wrote:
               | While I don't have any factual proof to refute your
               | statements, in my personal experience almost every
               | organization uses NAT & RFC1918 address space. The only
               | client I can think of in my 20 years of experience that
               | used a public IPv4 per VM/machine was the DoD,
               | specifically, the U.S. Army.
               | 
               | From your very last statement, I think you've confused
               | self hosting (like buying a VPS from Digital Ocean and
               | hosting your own blag) and how the real world works (like
               | going to Dell.com and ordering a new laptop). "The
               | mainframe" these days is almost always behind a L4/L7
               | load balancer or other network device and very rarely
               | directly addressable.
        
               | SoftTalker wrote:
               | Big universities (at least in my experience in the USA)
               | are the other ones that would have a public IP address
               | for every device, at least until rather recently. They
               | were online very early and got allocated huge blocks of
               | addresses, before anyone really imagined future scarcity.
        
             | ehPReth wrote:
             | Who's the monster that created NAT for IPv6 D:
        
           | jeroenhd wrote:
           | Every consumer and professional router I've seen comes with a
           | deny rule for incoming traffic by default, unless the device
           | is configured as a "router router", like inside an ISP.
           | 
           | NAT has many problems because people rely on it for security.
           | For example, many shitty IoT devices and even consoles
           | (looking at you, Nintendo Switch) tell you to put their
           | device in the DMZ to make them work.
           | 
           | The norm for IPv6 in practice is that you've got your
           | firewall on and need to make exceptions for ports you want
           | open, just like on IPv4, except that with IPv6 you don't need
           | some kind of interactive state machine attackers can confuse
           | and abuse running inside your router's kernel (ALG).
        
           | asveikau wrote:
           | > Granted I assume you can probably create a default DENY
           | rule for inbound traffic and selectively open ports up as
           | exceptions. Right?
           | 
           | That's what reasonable people would do for a V4 network too.
        
         | d00bianista wrote:
         | > Not having two sets of firewall rules and two sets of
         | everything. I always disable IPv6 because it can bite you so
         | hard when you don't realize that you are wide open to IPv6
         | connections because of different firewalls.
         | 
         | nftables gives us a dualstack firewall, and it's so far the
         | only one I've seen. It's not that bad, but I have occupational
         | damage so I don't mind :D
         | 
         | https://wiki.nftables.org/wiki-nftables/index.php/Nftables_f...
        
         | Hikikomori wrote:
         | Elad Cohen?
        
         | fleventynine wrote:
         | How is a host with a 32-bit address supposed to communicate
         | with a host with a 128-bit address when it can only send
         | packets with a 32-bit address?
        
           | jk_i_am_a_robot wrote:
           | That's a solved problem whose solution is called ipv4 over
           | ipv6 tunneling.
        
             | stevefan1999 wrote:
             | that will cause state and can hurt performance since it
             | needs extra memory. one of the main selling point of IPv6
             | is try to be stateless as much as possible to ease up on
             | routers and switches
        
               | toast0 wrote:
               | Where's the need for state? Please excuse the abuse of
               | terms below, but you can probably figure out what I mean.
               | 
               | A v6 only host would send a v6 packet from it's full
               | address to the v4+ address. A router on the path that has
               | access to v4 internet would pull the v4 destination out,
               | and reframe as a v4 packet (source ?, dest the v4
               | address), that's got the v6 packet, or maybe just the
               | addresses, I dunno. This router would burn a lot of CPU
               | doing this, but doesn't need any state.
               | 
               | The v4+ host has a little harder job, it needs to know a
               | v4 address to send the tunneled packets to. But again,
               | it's sending a tunneled packet, and whatever is
               | processing that doesn't need state, it just needs cpu to
               | inspect and untunnel. Of course, if the v4+ address is
               | rfc1918 (or otherwise unroutable), then that's
               | problematic. You _could_ do NAT at the router, but I'd
               | say don't do that.
               | 
               | It _might_ be useful for the v4 host to keep the v4
               | tunnel sender IP from incoming addresses to reframe on
               | the back end.
               | 
               | You might also do something special with routing to the
               | v4+ prefix... if you advertise the v4+ address, it
               | indicates you want v6 -> v4+ traffic to go to your
               | network as v6 and you'll encapsulate it, otherwise it
               | would go a (hopefully local) router that advertised the
               | /96 prefix. If this encap/decap turned out to be popular,
               | you might see router ASICs accelerate it, but likely it's
               | expensive, so the work should be distributed to end
               | points as much as possible.
               | 
               | Of course, there was Teredo that kind of tried to do
               | something like, but it didn't really work out, did it?
        
               | Dagger2 wrote:
               | You're more or less describing 6to4. It's already a thing
               | in v6.
        
               | ipython wrote:
               | It's mostly a solved problem as most mobile network
               | operators are ipv6 only now. My iPhone only has an ipv6
               | address for example.
        
           | redox99 wrote:
           | If it's not "Ipv4+" aware, it wouldn't be able. Otherwise it
           | would understand new packet formats.
        
             | ilyt wrote:
             | So exactly like current situation, with content providers
             | forever stuck at providing old version for old clients.
        
               | redox99 wrote:
               | The difference is that this ipv4+ would be easier more
               | gradual and less scary to adopt. I edited my original
               | comment to explain a bit more.
        
             | [deleted]
        
         | hotpotamus wrote:
         | I generally agree, but I'm pretty sure ::1.2.3.4 is a valid
         | IPv6 address because it does have the idea of v4 compatibility
         | built in.
        
         | throw0101a wrote:
         | > _And regarding compatibility, with ipv4+ if you have a
         | 0.0.0.0.x.x.x.x ip address you would be able to talk to both
         | ipv4+ aware and legacy ipv4 devices natively without any
         | tunneling (because you also own the legacy, non quad 0 ip
         | address)._
         | 
         | This exists:
         | 
         | > _Addresses in this group consist of an 80-bit prefix of
         | zeros, the next 16 bits are ones, and the remaining, least-
         | significant 32 bits contain the IPv4 address. For example,
         | ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A
         | previous format, called "IPv4-compatible IPv6 address", was
         | ::192.0.2.128; however, this method is deprecated.[61]_
         | 
         | *
         | https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
         | 
         | * https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5
         | 
         | You _still_ need to upgrade bit of networking kit between the
         | source and destination to understand  "IPv4+", and this (lack
         | of) upgrading and enabling is what is hampering deployment.
         | 
         | What makes you think that companies would have been willing to
         | make the effort to deploy "IPv4+" any more than IPv6?
        
           | theamk wrote:
           | Mayne RFC exists, but it os not used in teal world anywhere.
           | In all servers, I configure IPv4 and IPv6 separately. Network
           | setup is separate. DHCP daemons are separate. Firewall rules
           | are separate. Network monitoring is separate.
           | 
           | I would switch to that "IPv4+" system if it existed.. I am
           | willing to use latest software/standards to future-proof my
           | setup, but duplicating all the work is too much for me.
        
             | throw0101a wrote:
             | > _I would switch to that "IPv4+" system if it existed.. I
             | am willing to use latest software/standards to future-proof
             | my setup, but duplicating all the work is too much for me._
             | 
             | And _exactly how_ would you accomplish this switch to a
             | larger address space? Please explain the steps _exactly_
             | how they would be done.
             | 
             | Because IPv4 has 32 bits of address. Anything after IPv4
             | needed >32 bits of address. How _exactly_ do you fit in _>
             | 32b_ in a data structure that is _only 32b_? You cannot.
             | 
             | So you have to go and replace every bit of networking code
             | out there to change the data structures. You know, _like
             | was done to deploy IPv6_.
        
               | CountSessine wrote:
               | In theory this could be handled by stuffing the extra 96
               | bits in an IP extension header. But this solves nothing
               | because then any switch that isn't IPv4+ aware will route
               | packets incorrectly. Literally every single switch on the
               | internet needs to be updated/replaced before you could
               | start generating IPv4+ traffic otherwise the one outlier
               | will send your IPv4+ packets off to Uzbekistan.
               | 
               | OR
               | 
               | Maybe you don't use those 96 bits for routing. But then
               | it becomes nothing but a sort of subnet address and you
               | haven't fixed the routing table size problem. And
               | actually every endpoint needs to upgrade too because
               | endpoints that don't recognize the header extension will
               | generate crazy responses and confuse TCP packets from
               | different computers as coming from the same machine.
               | 
               | There's no useful and backward compatible way of
               | extending IPv4.
        
               | AnIdiotOnTheNet wrote:
               | Couple things:
               | 
               | 1) Instead of stuffing the extra 96 bits in an extension,
               | you stuff all 128 in the extension and use a reserved
               | unrouted address in the v4 header field. Devices with no
               | clue will just drop those packets.
               | 
               | 2) Pedantically, switches are layer 2 devices. Some some
               | of them act as routers also, but only routing is
               | relevant.
        
               | Dagger2 wrote:
               | Even better, instead of using a reserved unrouted
               | address, use the "IP version" header field, which
               | literally exists for this exact purpose.
               | 
               | I'm struggling to see how this would improve anything
               | over what v6 did though.
        
               | [deleted]
        
               | anyfoo wrote:
               | Devices with no clue of IPv6 also just drop those
               | packets. What have we gained?
               | 
               | The only thing I can imagine is that while you still need
               | to alter or replace every piece of equipment on the net,
               | software adoption would likely have been much easier and
               | thus immediately higher if 128 bit addresses were the
               | only change (I still don't see the benefit of tucking it
               | in as a field into IPv4, but if IPv6 was just IPv4 with
               | wider addresses), and all the other protocols and
               | semantics that were changed with IPv6 stayed the same.
               | But arguably, since you do need to change every piece of
               | equipment, this was the time to make desirable,
               | fundamental, not-backward compatible changes, and
               | possibly the only opportunity at that.
        
               | theamk wrote:
               | Or you extend on network level, and even kernel level,
               | but keep programming API compatible. I don't think people
               | like IPv4 packets that much, it is all the APIs which are
               | giving problem.
               | 
               | I bet if we kept everything about IPv6 the same, but (1)
               | made IPV6_V6ONLY mandatory and default to zero (2) did
               | not use colon in IP address representation (3)
               | recommended firewalls use same config rules for IPv4/IPv6
               | address.. then IPv6 would have significantly higher
               | adoption right now.
        
               | Spooky23 wrote:
               | You just need to do what the world did - NAT.
               | 
               | IPv6 is more than just address space extension. There's
               | all sorts of stuff packed in there that complicates the
               | process.
               | 
               | All mobile clients are behind CG-NAT. We should have
               | built standards around that instead of worrying about
               | extending IP space to Mars or whatever.
        
               | throw0101c wrote:
               | > _All mobile clients are behind CG-NAT._
               | 
               | Demonstrably false. T-Mobile US mobile clients are
               | IPv6-only and connect via IPv6 to IPv6 sites:
               | 
               | * https://www.youtube.com/watch?v=d6oBCYHzrTA
               | 
               | * https://www.youtube.com/watch?v=nNMNglk_CvE
               | 
               | NAT is only used to connect to IPv4-only hosts via DNS64
               | (with or without 464XLAT). As of 2022Q2, T-Mobile US has
               | 110 million customers:
               | 
               | * https://www.statista.com/statistics/219577/total-
               | customers-o...
               | 
               | One-third of the US population is connecting via
               | IPv6-only on a day-to-day, hour-to-hour basis every time
               | their smartphone reaches out over the radio.
        
               | theamk wrote:
               | OK:
               | 
               | Let's use "IPv4+" scheme as described by redox99: we
               | still have dotted-decimal, and IPv4 addresses are
               | guaranteed to be accessible via IPv4+ interface.
               | 
               | Right now, most application software need non-trivial
               | rewrite to add ipv6 support: it has to support 2 sockets
               | instead of 1, and ":" in address breaks basically every
               | address parsing function out there. With IPv4+, you do
               | search/replace "sockaddr_in"->"sockaddr_in4plus" and
               | AF_INET->AF_INET4PLUS. That's it -- since backward
               | compatibility guaranteed, my software still works on IPv4
               | system, and hostname parsing is not broken. There might
               | be some minor breakage (unexpected dependencies on struct
               | size or ipv4+ address string length), but it would be
               | way, way smaller than the mess IPv6 is in too.
               | 
               | Right now, I have to set up my firewall twice for ipv4
               | and ipv6. But with ipv4+? I should be able to write "-m
               | tcp --dport 80 -j ACCEPT" once and have it work with
               | both.
               | 
               | Right now, all the network monitoring tools have to have
               | separate "ipv4" and "ipv6" codepaths. But with ipv4+,
               | there could be only one codepath. Yes, packet parsing
               | will have to handle two different IP header format, but
               | once it's parsed, old and new are treated identically.
               | 
               | Sure, the network layer will be more complex. The IP
               | stack in kernel would need to determine if the address is
               | "short" or "long", and format packets differently (either
               | old or new format). The high-performance routers would
               | need to be rewritten. The TCP/IP network card offload
               | will need to accommodate new format.
               | 
               | But this would be way, way less intrusive than current
               | IPv4->IPv6 transitions, because for each line of low-
               | level network code there are millions of lines of
               | application-level code, and for some totally stupid
               | reason the app code transition was made way harder than
               | needed.
        
               | anyfoo wrote:
               | I am not sure why you are downvoted, since you do make
               | some valid points. I myself am not sure whether the very
               | fundamental changes that IPv6 brings did not hamper its
               | adoption than if it was _just_ extended IPv4.
               | 
               | From a network administration perspective, sure, "you
               | need to replace every piece of equipment". But from a
               | software modification perspective (thinking more about
               | the software on network infrastructure equipment than
               | endpoints like applications), you have two very different
               | stacks.
               | 
               | On the other hand, if there was ever a time to make
               | (assumedly so) highly desirable compatibility-breaking
               | changes, that was it.
        
               | throw0101c wrote:
               | > _I should be able to write "-m tcp --dport 80 -j
               | ACCEPT" once and have it work with both._
               | 
               | Kind of like how PF does it?
               | tcp_services = "{ ssh, smtp, domain, www, pop3, auth,
               | pop3s }"         udp_services = "{ domain }"
               | block all         pass out proto tcp to any port
               | $tcp_services keep state         pass proto udp to any
               | port $udp_services keep state
               | 
               | *
               | https://docs.freebsd.org/en/books/handbook/firewalls/#pf-
               | tut...
               | 
               | If an address family ("af") is not specified, the rule
               | applies to both:                    [...]
               | pf-rule     = action [ ( "in" | "out" ) ]             [
               | "log" [ "(" logopts ")"] ] [ "quick" ]             [ "on"
               | ifspec ] [ route ] [ af ] [ protospec ]             hosts
               | [ filteropt-list ]               [...]               af
               | = "inet" | "inet6"               [...]
               | 
               | * https://www.freebsd.org/cgi/man.cgi?query=pf.conf
               | action [direction] [log] [quick] [on interface] [af]
               | [proto protocol]            [from src_addr [port
               | src_port]] [to dst_addr [port dst_port]]
               | [flags tcp_flags] [state]
               | 
               | * https://www.openbsd.org/faq/pf/filter.html#syntax
               | 
               | Perhaps the protocol isn't the problem and you're just
               | using firewall software that doesn't have very good
               | syntax?
        
             | icedchai wrote:
             | Ok. How do you increase address space without breaking the
             | protocol? IPv4 just doesn't have the space in the header.
             | Something like "v4+" can't happen for this reason.
             | 
             | You could argue that pervasive use of NAT beginning in the
             | late 90's _was_ "v4+". It bought us decades of Internet
             | growth, at the expense of true end-to-end connectivity.
        
           | nightfly wrote:
           | We've tried to roll out IPv6 at my work, and after several
           | years of it causing more issues than it help we turned it all
           | off again... We're gonna get back to it again this year, but
           | I can see many organizations just not doing that until
           | absolutely forced.
        
           | nikanj wrote:
           | > What makes you think that companies would have been willing
           | to make the effort to deploy "IPv4+" any more than IPv6?
           | 
           | Way less resistance from tech teams. Ultimately companies are
           | made of people, and ipv6 is partly a failure because working
           | with it requires a wholly new skillset
        
             | zamadatix wrote:
             | Maybe it's different on the software side but coming from a
             | network VAR it's the same skill set. You still have subnets
             | and routes and netmasks and DHCP or automatic assignments
             | the difference is the size. If you know IPv4 all you need
             | to learn is "the subnets are all /64 in size, addresses are
             | 128 bits, and you don't need DHCP if you don't want".
        
               | anyfoo wrote:
               | Yeah, but I have to say, even as someone who wants IPv6
               | to succeed and supersede IPv4, from the perspective of
               | building that network infrastructure software, I think
               | this "IPv4+" would have been massively simpler to add,
               | extremely so, and that may have aided adoption a lot.
               | 
               | It's really hard to overstate how much simpler tacking on
               | 128bit IP addresses to an otherwise unmodified protocol
               | would have been in the software stack of network
               | infrastructure.
               | 
               | But, as I also said a few times here, the time to make
               | desirable compatibility-breaking changes was exactly
               | then, when every piece of network equipment needed
               | massive alteration or replacement anyway. And I look
               | forward to the day IPv6 hopefully becomes predominant,
               | and the advantages it brings.
        
           | anthropodie wrote:
           | > What makes you think that companies would have been willing
           | to make the effort to deploy "IPv4+" any more than IPv6?
           | 
           | I'm pretty sure that those who built new protocol were aware
           | of this and were like "anyway we are gonna have to upgrade
           | network devices. Why don't we build a new protocol while
           | avoiding pitfalls of older one"
           | 
           | Any comittee that sat down to solve IPv4 issue would have
           | thought of compatibility first.
           | 
           | I am shocked that so many people agree with OP's armchair
           | solution here.
        
             | salmo wrote:
             | They took much more on with IPv6 than IPv4 replacement. The
             | spec goes much deeper than IPv4 did, replacing ARP, DHCP,
             | etc. It's a product of its time, including a lot of over-
             | engineering by committee. Many of the problems they tried
             | to address didn't pan out to be real issues. You can read
             | the RFCs and compare.
             | 
             | IPv4 w/ more bits is a lot more simple. Yes, older network
             | gear wouldn't deal with it well, but that's not a real
             | issue today because that same network gear supports IPv6.
             | 
             | Buuut, one of the biggest problems with app-level issues is
             | just that the app doesn't bother dealing with IPv6
             | addresses and AAAA records. It would be the same issue with
             | an imaginary IPv4*2.
        
         | fernandomm wrote:
         | Let's not forget about the idea that ISPs would distribute a
         | /56 range to residential users. You could split it in /64
         | ranges according to your requirements and everything would work
         | fine.
         | 
         | There is only one "minor" issue: all major ISPs in my country (
         | Brazil ) only provide a single /64. You can't get another /64
         | unless you upgrade to a very expensive business plan.
         | 
         | That makes IPv6 not only useless but also a huge security
         | issue.
         | 
         | 1) I can't use my Mikrotik as a firewall. Trying to split a /64
         | range breaks things and some devices ( specially IOT ones )
         | will simply not work.
         | 
         | 2) Routers provided by the ISPs here are very limited,
         | specially for things like firewall rules. Some of them will
         | only provide a On/Off switch, with Off option between the
         | default one.
         | 
         | Although IPV4 + NAT had some issues, it ( accidentally? )
         | created a safe/sane default config for non-technical users. In
         | order to open a port and expose a device, you have to
         | explicitly add a rule on the firewall.
         | 
         | IPv6 is the other way around. In practice, all devices and
         | ports are exposed unless you explicitly block it.
         | 
         | In the last 3 years I've noticed criminals focusing more and
         | more on IPv6 scans to compromise devices and create botnets
         | since it's much easier to find exposed/unpatched devices as
         | most users don't understand how to correctly configure a
         | firewall.
         | 
         | Most of the time, the only viable solution is to disable IPv6.
        
           | pantalaimon wrote:
           | If I understand correctly, variable SLAAC tries to fix this
           | by allowing you to further split a /64
           | 
           | https://datatracker.ietf.org/doc/draft-mishra-6man-
           | variable-...
        
           | aidenn0 wrote:
           | > There is only one "minor" issue: all major ISPs in my
           | country ( Brazil ) only provide a single /64. You can't get
           | another /64 unless you upgrade to a very expensive business
           | plan.
           | 
           | I'm curious why you need multiple subnets at home; I at one
           | point had separate subnets because I was using a wifi client
           | as a ip level router, but was wondering what your use-case
           | is.
           | 
           | > Although IPV4 + NAT had some issues, it ( accidentally? )
           | created a safe/sane default config for non-technical users.
           | In order to open a port and expose a device, you have to
           | explicitly add a rule on the firewall.
           | 
           | > IPv6 is the other way around. In practice, all devices and
           | ports are exposed unless you explicitly block it.
           | 
           | I would like to humbly suggest that you don't remember what
           | the internet was around the turn of the century with devices
           | configuring IGD via UPnP so every device you hooked up to
           | your home router automatically setup a port-mapping to put
           | itself on the open internet.
           | 
           | Eventually everyone realized this sucked and UPnP NAT
           | traversal was disabled everywhere. The same will happen (and
           | actually more-or-less has already happened) with default-
           | allow home routers switching to default-block.
        
           | epx wrote:
           | Same situation, I use IPv6 NAT and VPN, huge letdown but
           | c'est la vie.
        
           | crest wrote:
           | RouterOS v7 supports DHCPv6 prefix delegation. You can
           | request a delegated /64 per downstream interface and announce
           | itself as router using these prefixes. You can still use your
           | MikroTik device as router, stateful firewall, proxy. You
           | don't have to mess with smaller than /64 allocations on links
           | unless your provider forces a broken CPE on you that doesn't
           | support DHCPv6 prefix delegation.
           | 
           | Have you actually seen any large scale deployments of CPEs
           | without an active IPv6 firewall blocking incoming connections
           | by default?
        
             | pantalaimon wrote:
             | Fritz!OS also does, it's used by many consumer routers in
             | Germany. There is of course also OpenWRT.
        
             | icedchai wrote:
             | I am doing this on my pfSense box. My ISP delegates me a
             | /56 and I have them assigned to several different VLANs.
        
         | cramjabsyn wrote:
         | I feel the same way.
         | 
         | Clearly ipv6 is very flawed and by now the community should
         | consider it a failure and work on a viable replacement.
         | 
         | We need an internet protocol that is backwards compatible with
         | ipv4 and does not require deploying and maintaining entirely
         | parallel networks, interfaces, firewalls, routing, etc.
         | 
         | If ipv6 actually was viable, the internet would have cut over.
         | Instead we're on a path to support ipv4 and ipv6 in parallel
         | essentially forever.
        
           | neilalexander wrote:
           | There is no "backwards compatible with IPv4". If you have to
           | modify the existing packet headers, you no longer have
           | backward compatibility. If you change anything involving how
           | a flow is identified (like the source/address destinations
           | and ports) then you have broken backward compatibility.
           | Firewalls need to understand new address formats, routers
           | need to understand new address formats, end systems need to
           | understand new address formats, BGP needs to be extended to
           | support new address formats.
           | 
           | IPv6 is perfectly viable and it is in many ways cleaner than
           | IPv4 is. It's just that transition is expensive and apathy is
           | easy.
        
             | cramjabsyn wrote:
             | > It's just that transition is expensive
             | 
             | It's impossible to finish a transition when the old version
             | has no end of life in sight.
        
               | kd913 wrote:
               | >It's impossible to finish a transition when the old
               | version has no end of life in sight.
               | 
               | The end of life is gonna happen when ipv4 addresses end
               | up being cost prohibitive. They are already some $50 an
               | ip address.
               | 
               | That is gonna be cost prohibitive in developing
               | Countries, who already are making a transition to ipv6.
        
               | uuddlrlrbaba wrote:
               | Increased demand will drive the price up, but that's not
               | end of life.
               | 
               | Developed countries will pay obscene amounts for ipv4
               | space. Just as they do for shorthand .com domains.
        
               | kd913 wrote:
               | That cost will continuously rise up until migration to
               | ipv6 comes out cheaper and enables access to the
               | developing market as well. At which point it is a
               | business no brainer.
        
               | icedchai wrote:
               | IPv4 will never disappear, it will just fade into
               | obscurity. (We'll probably be dead and buried long before
               | that time.)
        
               | Dagger2 wrote:
               | Just like IPX. It's still necessary and in use for some
               | things -- so it hasn't reached its end of life -- but
               | when was the last time you ever thought about it?
               | 
               | By this metric, we still haven't finished migrating to
               | v4.
        
               | __d wrote:
               | I'm curious: what still uses IPX in 2022?
        
               | icedchai wrote:
               | True. I could see a world where IPv4 is only for legacy,
               | internal systems and it is not routed externally, but
               | that feels like decades away. There would need to be a
               | coordinated effort of major ISPs to turn it off, but why
               | would that happen if people are willing to pay for it?
        
         | EvanAnderson wrote:
         | There was an idea floated in the early 2010s to do an overlay
         | network over IPv4 that did this just:
         | https://seam.cs.umd.edu/EnhancedIP/index.html
         | 
         | It "died" as an Internet-Draft:
         | https://datatracker.ietf.org/doc/html/draft-chimiak-enhanced...
        
         | WastingMyTime89 wrote:
         | It's already more or less how IPv4 addresses are embedded in
         | IPv4 (except its 128bits and they use an FFFF prefix between
         | the 0 and the IPv4 address).
         | 
         | IPv6 doesn't solve anything for the sake of it. Anyone who had
         | to debug ARP caused issue on a network knows it's complete
         | garbage for example.
         | 
         | Providers who explain that they are dragging their feet because
         | of the complexity would have said exactly the same thing even
         | it was only IPv4++. They just don't want to invest _any_ money
         | in something which is working for them.
        
         | twblalock wrote:
         | IPv6 is the Python 3 of networking, although adoption is taking
         | far longer than Python 3. Hopefully the lesson has been learned
         | and this won't happen again.
        
         | blablabla123 wrote:
         | It provides a lot of improvements actually. Stating the
         | obvious, NAT isn't needed anymore. Also with modern Firewalls
         | rules need to be written only once. At this point I'm just
         | surprised why it's not adopted
        
           | tinus_hn wrote:
           | ISPs love NAT because it is an artificial distinction between
           | producers and consumers, which means they can call the
           | producers 'pro' of 'enterprise' and charge them through the
           | nose while the consumers can't cause trouble and just pay for
           | download speed.
        
             | eppp wrote:
             | Going by my current experience of managing an ISP, the
             | number of people that care at all about producing anything
             | is almost zero. Out of thousands of accounts I can count on
             | two hands the number of people that want anything outside
             | of the standard ipv4 symmetric 1gb we offer.
        
               | bo1024 wrote:
               | When infrastructure makes it really hard for people to
               | produce things, then there's no ecosystem for it and very
               | few people get interested in producing things.
               | 
               | At-home hosting would open up tons of applications. You
               | could have at home video cameras that are actually
               | private (no third party connection). You could share
               | photos with family and friends from a home photo frame -
               | directly. There could be tons of applications that normal
               | people would be interested in.
        
               | tinus_hn wrote:
               | Perhaps the don't say they care about producing content
               | but surely they care about accepting (voip) phone calls,
               | being able to torrent twice as fast (because they would
               | be able to connect to twice as much peers) and they'd
               | also like all these services that just don't exist
               | anymore because too many people are behind NATs they
               | can't control.
               | 
               | The popularity of uPnP for automatic port forwarding
               | should be a clue, anything that uses that is blocked by
               | cgnat.
        
           | patrakov wrote:
           | > NAT isn't needed anymore.
           | 
           | False.
           | 
           | The most obvious case is multi-homing (for redundancy, fail-
           | over, and policy-routing reasons) without an AS available and
           | thus without BGP. In other words, a typical case when a user
           | has a fiber connection and LTE as a backup. Then it is the
           | router who should pick the correct source address, according
           | to the link which is up.
           | 
           | Another reason is to deal with dynamic addressing from the
           | ISP. Let's suppose we have an ADSL PPPoE connection, with
           | prefix delegation. The modem connects, gets a prefix, devices
           | grab IPs from it. Then a rat chews upon the line, causing a
           | disconnection and a reconnection - but the ISP now delegates
           | a different prefix. Or worse - the modem crashes and reboots,
           | also picking up a different prefix. Devices are still not
           | picking up such unexpected renumberings well. So they
           | continue using old addresses, which don't work. Using a layer
           | of network prefix translation solves the problem, as now only
           | the router needs to be aware of the renumbering that has just
           | happened due to the rat.
        
             | zekica wrote:
             | The correct way to do this is to advertise the fiber
             | connection's prefix to devices on LAN as long as that
             | connection is available. When it fails, the router should
             | send RA with zero as the expiry time for that prefix, and
             | include the LTE prefix. This way, all devices will
             | immediately start using the new prefix. You can use ULA in
             | addition so local connections don't fail.
        
               | patrakov wrote:
               | This can work with the fiber + LTE example, and with the
               | rat example, but does not cover the "modem crash"
               | example. The ADSL modem does not know its old prefix, and
               | thus cannot send zero-expiry-time announcements for it.
               | 
               | Also consider a case where there is an ADSL modem (with
               | the ISP giving out /56 via prefix delegation) and a home
               | lab with virtual machines, that are behind a
               | virtualization host, which grabs a subprefix (let's say a
               | /64, separate from the main home LAN /64 prefix) for its
               | VMs from the modem via DHCPv6. While there is indeed a
               | mechanism for flash renumbering over SLAAC, which may
               | work for devices in the home LAN, there is also a need to
               | invalidate the subprefix delegated for virtual machines
               | via DHCPv6 through the virtualization host. Last time I
               | checked, this is not implemented anywhere.
        
             | throw0101a wrote:
             | >> * NAT isn't needed anymore.*
             | 
             | > _False._
             | 
             | "IPv6 Multihoming without Network Address Translation"
             | Network Address and Port Translation (NAPT) works well for
             | conserving        global addresses and addressing
             | multihoming requirements because an        IPv4 NAPT router
             | implements three functions: source address
             | selection, next-hop resolution, and (optionally) DNS
             | resolution.  For        IPv6 hosts, one approach could be
             | the use of IPv6-to-IPv6 Network        Prefix Translation
             | (NPTv6).  However, NAT and NPTv6 should be        avoided,
             | if at all possible, to permit transparent end-to-end
             | connectivity.  In this document, we analyze the use cases
             | of        multihoming.  We also describe functional
             | requirements and possible        solutions for multihoming
             | without the use of NAT in IPv6 for hosts        and small
             | IPv6 networks that would otherwise be unable to meet
             | minimum IPv6-allocation criteria.  We conclude that
             | DHCPv6-based        solutions are suitable to solve the
             | multihoming issues described in        this document, but
             | NPTv6 may be required as an intermediate solution.
             | 
             | * https://datatracker.ietf.org/doc/html/rfc7157
        
               | qwertywert_ wrote:
               | I just did a quick read but I don't understand how this
               | would help the case of your Gateway ethernet link going
               | down temporarily and switching to Cellular WAN?
               | 
               | The client would still need some smart steering to select
               | the correct route no? Does the gateway invalidate the
               | ethernet address somehow? But with NAT you don't need to
               | worry about it.
        
           | trynewideas wrote:
           | Inertia on the part of large services, providers, and
           | infrastructure isn't much of a surprise.
        
         | mplabelspace wrote:
        
         | andix wrote:
         | I think the big problem of ipv6 is, that it's not backwards
         | compatible. You can't just switch to ipv6 only and have a some
         | network box rewrite ip addresses for example 1.2.3.4.5.6.7.8 to
         | 10.6.7.8 or simple kernel module that translates it.
         | 
         | Just imagine if ipv6 stacks could just completely replace ipv4
         | stacks on every system, with full access to all ipv4 resources,
         | as long as the first 12 bytes are all 0.
        
         | secondcoming wrote:
         | "::ffff:1.2.3.4" is a valid IPv6 address; "IPv4-mapped IPv6"
        
       | candiddevmike wrote:
       | I think IPv6 internal-only is viable with some kind of NAT64
       | setup, maybe not at scale though. What is everyone using for
       | NAT64?
        
         | gurrone wrote:
         | Would use OpenBSD + unbound to get NAT64 + DNS64. I'd prefer a
         | dual-stack setup with RFC1918 IPv4 internally + a NAT44 gateway
         | and IPv6 "just" on top. Drawback: if you find yourself to have
         | to do a lot of firewalling it essentially doubles your work.
        
         | noipv6 wrote:
         | & for "at scale" - how about 100,000,000 users?
         | 
         | https://twitter.com/iPv4depletion/status/1584376525427978240
        
         | noipv6 wrote:
         | afaik jool is the currently-recommended foss nat64 (since tayga
         | is apparently unmaintained)
         | 
         | alot of commercial vendors have mature nat64 implementations
         | tho
        
           | rnhmjoj wrote:
           | Jool also has the best documentation I've ever seen. It does
           | not only explain how to configure the software but it also
           | has illustrated explanations that do a far better job than
           | the actual RFCs in describing the motivation and use cases of
           | the many protocols it supports.
        
       | myself248 wrote:
       | I propose a real simple solution:
       | 
       | Major providers pledge to take this seriously. They toss a rule
       | in their routers that just drops all ipv4, for 1 minute, starting
       | at noon UTC. At 12:01 UTC, revert the change and ipv4 works
       | again. Do this every day.
       | 
       | The following week, up it to 2 minutes.
       | 
       | The incentive will happen.
        
         | rhacker wrote:
         | While I think this would effectively move the needle, as soon
         | as they announce that this is going to happen, I am guessing
         | heart monitors, ankle brace companies (people in home jail) and
         | a slew of weird other use cases will pop up as major problems
         | and the effort will fail.
        
           | myself248 wrote:
           | All of those things should be able to cope with a 1-minute
           | loss of connectivity already. To do otherwise would be
           | astonishingly negligent.
        
         | hanche wrote:
         | Or as a friend of mine suggested, more than ten years ago and
         | only half in jest, I think: just block all porn sites on IPv4
         | (but not on IPv6). The demand for IPv6 will soon be
         | overwhelming.
        
         | jl6 wrote:
         | Of course it's simple if you have the capability to compel
         | coordinated action across a globally-distributed disparate-and-
         | not-easily-definable group of stakeholders whose incentives
         | typically do not align.
        
       | topspin wrote:
       | > The GitHub API and its code load endpoints are not reachable
       | via IPv6
       | 
       | Should it matter that GitHub or whatever doesn't support IPv6? I
       | understood that it is possible to bridge the divide through an
       | IPv6<->IPv4 gateway. IPv6 is designed to incorporate the IPv4 32
       | bit address space as a segment of the IPv6 address space and
       | automatically translating between the two is relatively
       | straightforward.
       | 
       | At least that what I believe. The next time someone asks me about
       | supporting IPv6 will be the first, so I've been able to avoid the
       | matter for a couple decades now.
        
         | Dagger2 wrote:
         | That's NAT64. It's something that Hetzner could and should be
         | providing for their customers, but as far as I can see they
         | aren't.
        
           | topspin wrote:
           | Well ok... the problem stops right there then. Why would
           | anyone expect -- given the low adoption of IPv6 -- IPv6 sans
           | NAT64 to be workable? Why even bother without it?
           | 
           | I don't imagine it would be hard to locate any number of IPv6
           | zealots proselytizing a NAT64-less world, but here we have
           | someone that made a legitimate effort to apply IPv6 and
           | failed because it wasn't there. One fewer potential convert
           | added to the pile...
        
       | rwky wrote:
       | We enable IPv6 on CDNs e.g. Cloudfront/Cloudflare and load
       | balancers, never had an issue and I do see IPv6 traffic hitting
       | them. Apart from that it doesn't see much use. Personally I don't
       | use IPv6 since I've never had and ISP with at home or on mobile
       | living in the UK.
        
       | xmddmx wrote:
       | Many small business routers and firewalls still don't have
       | reasonable IPv6 support, for example
       | https://forum.peplink.com/t/ipv6-support/3675/54 (from 2015) says
       | they are working on it. People are asking "what's the status" now
       | in 2022.
        
       | noipv6 wrote:
       | reiterating the first comment on this thread, which got flagged
       | (maybe it won't be this time):
       | 
       | :reads that ppl aren't taking ipv6 seriously on hn:
       | 
       | "oh, i don't need to take ipv6 seriously either"
       | 
       | :doesn't do anything w/ ipv6:
       | 
       | :time passes:
       | 
       | :someone tries ipv6-only, complains about it on hn:
        
       | tristor wrote:
       | Unfortunately this is true. I've been running IPv4/IPv6 dual
       | stack since 2014 for most of my infrastructure and since 2016 for
       | all of it. The company I work for now is a major AWS customer,
       | and we managed to pressure them into enabling IPv6 for Global
       | Accelerator, and have just recently launched full IPv4/IPv6 dual
       | stack for our endpoints... in 2022.
       | 
       | I think that the primary root cause of this is economics, if
       | we're being perfectly blunt. The countries/regions of the world
       | that got most of the IPv4 address space are also the places where
       | most of the money is, so businesses, especially businesses
       | serving businesses, are not heavily driven to support IPv6 other
       | than as a "checkbox", because their customers all have IPv4 and
       | are not asking for it. Meanwhile in APJC/BRIC IPv6 is the
       | dominant mode of connectivity, and many major businesses are IPv6
       | only or IPv6 primary w/ IPv4 CGNAT. When you enter into this
       | market, IPv6 quickly becomes a requirement, however in EU/NA,
       | it's just not required.
       | 
       | I am seeing this shift though, because of mobile-first consumer-
       | oriented businesses. Globally, pretty much all mobile providers
       | issue only IPv6 addresses that are globally routed to their
       | subscriber devices and utilize CGNAT to get IPv4 connectivity.
       | This is true even in North America. The problem is that CGNAT is
       | /really/ good as far as "working", so from the perspective of
       | endpoints they communicate with, it may not be obvious that IPv6
       | would actually benefit them. For mobile applications, IPv6 has a
       | significant performance advantage because it skips CGNAT, and so
       | at least in that space businesses are doing more to support it
       | directly.
        
         | kevin_nisbet wrote:
         | That's really cool that global accelerator got support, I was
         | about to bash AWS. It's one of those things when trying to
         | optimize product market fit and quick launches, that we needed
         | global accelerator, but not IPv6 on a project I worked on.
         | 
         | So when major AWS / cloud services don't have the ability to
         | just turn it on, is one part of the chicken and egg that
         | contributes to the lack of adoption. Thanks for pressuring for
         | that support.
        
           | tristor wrote:
           | Yep, there are unfortunately some other AWS services that
           | still don't support IPv6, but at least with Global
           | Accelerator and ALB support, we can hide that from end-
           | customers that require IPv6 endpoints.
           | 
           | https://aws.amazon.com/blogs/networking-and-content-
           | delivery...
           | 
           | ALB/ELB/NLB support for IPv6 is fairly recent as well,
           | November 2021: https://aws.amazon.com/about-aws/whats-
           | new/2021/11/applicati...
        
             | miyuru wrote:
             | AWS have a documentation page which display everything that
             | supports IPv6 in a single place. They are definitely
             | working on supporting IPv6 only.
             | 
             | https://docs.aws.amazon.com/general/latest/gr/aws-
             | ipv6-suppo...
        
       | bombcar wrote:
       | Setting a website to be available over IPv6 is relatively easy,
       | yet we see:                   ;; QUESTION SECTION:
       | ;news.ycombinator.com.  IN AAAA
       | 
       | Why? Because it's _not_ quite as simple as making Apache respond
       | over IPv6; any website of any size has various protections in
       | place to prevent DDoS, spam, etc, and those tools are almost
       | universally _basic_ and at the root is the  "ban by IPv4
       | address". Without that tooling supporting IPv6, it remains a side
       | note not worth supporting.
       | 
       | Solutions? You can make an IPv6 version available that is read-
       | only; or requires you to login via an IPv4-only gateway first
       | (and protect that) and then ban by username as necessary.
       | 
       | And outbound? You have to IPv4 NAT which maybe Hetzner offers? If
       | not there are things like https://nat64.net
        
         | miyuru wrote:
         | Actually HN is available via IPv6 over Cloudflare. You have to
         | add a CF IPv6 it to the hosts file.
         | 
         | In fact I am posting this comment over IPv6.
        
           | mort96 wrote:
           | Your comment has no useful information.
        
             | lzaaz wrote:
             | Put this in your /etc/hosts file and it should work (I
             | don't know if it does as I don't have ipv6)
             | 
             | 2a06:98c1:3120::5 news.ycombinator.com
        
               | jeroenhd wrote:
               | Can confirm, works like a charm!
        
               | mort96 wrote:
               | Which is not useful information in this discussion.
        
               | dang wrote:
               | Ok, but please don't respond to a bad comment (or one you
               | feel is bad) by posting bad comments yourself. That only
               | makes everything worse.
               | 
               | A better way to counter comments that don't contain
               | useful information would be to add some useful
               | information; or perhaps to post a question explaining
               | what information is missing and asking for it.
               | 
               | https://news.ycombinator.com/newsguidelines.html
        
           | watt wrote:
           | The fact anyone should think this is somehow acceptable state
           | of art is obscene to me.
        
           | cryptonector wrote:
           | > hosts file
           | 
           | 1986 wants a word.
        
             | miyuru wrote:
             | I actually run a separate DNS proxy that does it
             | automatically for me. (HN and lot of other sites)
             | 
             | I only mentioned hosts file because it is the easiest way
             | to spoof the domain.
        
               | cryptonector wrote:
               | That's still the same thing: you're manually adding a
               | mapping where you shouldn't have to. HN should just
               | publish the AAAA RRs and be done.
        
           | trynewideas wrote:
           | > You have to add a CF IPv6 it to the hosts file.
           | 
           | That's worse, yeah? You do see how that's worse?
        
         | jeroenhd wrote:
         | > Why? Because it's not quite as simple as making Apache
         | respond over IPv6; any website of any size has various
         | protections in place to prevent DDoS, spam, etc, and those
         | tools are almost universally basic and at the root is the "ban
         | by IPv4 address". Without that tooling supporting IPv6, it
         | remains a side note not worth supporting.
         | 
         | The consensus I've seen is to treat IPv6 /56s or /48s
         | (depending on preferred strictness) as an IPv4 address. From
         | there, it's quite simple to port the security mechanisms.
         | 
         | Of course the chicken/egg problem comes back, because many of
         | these "solutions" don't support IPv6 because nobody asked them
         | to support IPv6 because they don't use IPv6 because their
         | solutions don't support IPv6.
         | 
         | As for HN, good question. Adding a simple line to your DNS
         | server or hosts file to make HN resolve on IPv6 is enough to
         | get it to work.
         | 
         | Edit: emailed dang, it's on the roadmap!
        
       | ipython wrote:
       | I have to say I'm super disappointed in the ignorance and
       | negativity in the comments on this thread. Ignorance of both the
       | difficulties inherent in upgrading a fixed size wire protocol
       | designed for a research network fifty years ago, and the
       | widespread adoption of ipv6 for real customer deployments. Heck
       | most of you are probably using ipv6 through your mobile carrier
       | and don't even know it!
        
         | gnfargbl wrote:
         | I think you're being unfair to the audience. The main
         | complaints here aren't about the consequences of those legacy
         | problems, they're about the fact that IPv6 is just such a
         | mediocre designed-by-committee protocol.
         | 
         | Your point about mobile networks kind of illustrates this.
         | There are all sorts of weird and wonderful protocols used in
         | the mobile world, and it doesn't matter because 99.999% of us
         | never have to deal with it, and the 0.001% that do have time
         | and space to become experts. IPv6 isn't like that -- it needs
         | to be a consumer grade protocol that people can understand and
         | work with. It either fails that test, or perhaps at best
         | scrapes a borderline pass. We deserved better.
        
           | zamadatix wrote:
           | IPv6 is very similar to IPv4 it's just IPv4 wasn't a consumer
           | grade protocol either. The problem isn't the protocol it's
           | that there is little incentive for the average user to switch
           | to anything else on their own volition when most didn't even
           | really set up what they are switching from (and already
           | working on today) anyways.
        
             | gnfargbl wrote:
             | Again, this is kind of making my point. IPv4 had an
             | _excuse_ for being a bit crap, because it was designed in
             | the early 1980s. IPv6 should have been much better than it
             | is.
             | 
             | Adoption was always going to be slow, but it never needed
             | to be this slow. If the designers had thought a but more
             | about usability and not done stupid stuff like making the
             | address space contain twice as many bits as it actually
             | needs, then we would have transitioned by now.
        
               | ipython wrote:
               | It should be mentioned that 2^32 was widely considered to
               | be unfathomongly large when ipv4 was developed as well.
               | 
               | However now we are pumping out something like 4 ARM cores
               | per person on the planet, per year. Clearly we will need
               | to plan for those devices to communicate.
               | 
               | Also the effective address space in ipv6 is much smaller
               | than 2^128 as the default subnet prefix is /64. So in a
               | sense, it has already "addressed" your concern? Pun
               | intended.
        
               | NegativeK wrote:
               | IPv6's introduction is closer to IPv4's introduction that
               | to now. By nearly twice as much.
        
           | ipython wrote:
           | What parts of ipv6 used in consumer grade equipment are not
           | understandable or "consumer grade"? Ipv6 in some areas is
           | actually simpler than ipv4.
           | 
           | I gave the example of mobile networks because it's one of the
           | few places consumer facing networks are growing rapidly and
           | in some cases build entirely greenfield networks. And they
           | have overwhelmingly chosen to build using ipv6 to do so.
        
       | jmbwell wrote:
       | All our internal systems use IPv6. Internal traffic is almost
       | totally IPv6. Traffic to/from the public Internet on our networks
       | is 30-40% IPv6.
       | 
       | We just started treating it like a first class citizen and worked
       | through the learning experiences, and it quit seeming like such a
       | big deal.
       | 
       | IPv6-only, when interfacing with the public internet or the
       | public cloud (which we don't much use), does seem like a
       | challenge, but only due to external factors.
       | 
       | It's no more difficult to get a handle on it than any other
       | technology, at which point it pretty much becomes routine.
        
       | maltris wrote:
       | Various software vendors who dont support IPv6 and render IPv6
       | only setups without any kind of tunneling useless. And for the
       | worst part play it down with stupid reasons in 202x. My favs "Why
       | you need IPv6, just use 6to4 tunnels", "what do you mean IPv6
       | only?", "We dont have the resources", "It will take some time die
       | to major changes in the software" - jesus...
       | 
       | I tried running IPv6 only with one machine (VPS in own
       | hypervisor) but gave up after 2-3 hours of yak shaving and
       | quickfixing things that should just work out, official Ubuntu
       | repos not speaking v6 was one of them.
        
       | AdamH12113 wrote:
       | Given how long it's been since IPv6 was released, I'm surprised
       | that there hasn't been a big proposal for an IPv7 that would fix
       | the alleged problems with IPv6. Has anyone worked on anything
       | like that?
        
         | mprovost wrote:
         | It's more the case that the panic around IP space exhaustion
         | turned out to be unfounded - or at least we've been able to
         | work around it for much much longer than expected. Back in 1994
         | the IETF predicted that the internet would stop working in 3-7
         | years. Almost 30 years later we're still going. So there's no
         | sense of urgency to invent something better.
         | 
         | For the record I also believe that v6 will be abandoned and
         | eventually replaced, most likely with a backwards-compatible
         | protocol. Or something that provides a more compelling reason
         | to upgrade than v6, which basically has nothing. Or at least
         | nothing that people want - the lack of NAT is really an anti-
         | feature.
         | 
         | The history of tech is littered with "standards" that never
         | achieved critical mass.
        
           | Dagger2 wrote:
           | v6 already is backwards compatible. Pretty much every form of
           | backwards compatibility that is possible with v4 is available
           | in v6.
           | 
           | The problem is that v4 isn't _forwards_ compatible with
           | larger address spaces, and that 's a problem that _any_
           | protocol with  >32-bit addresses faces, because it's a
           | problem with the design of _v4_ , not the design of the new
           | protocol. Replacing v6 will not help.
           | 
           | > the lack of NAT is really an anti-feature.
           | 
           | v6 doesn't lack NAT -- what it lacks is any sane reason to
           | use NAT. That's a _good_ thing.
        
         | Arnavion wrote:
         | The "alleged problems" are not with IPv6. They're with not-
         | IPv4.
        
       | psyclobe wrote:
       | I tried to deploy ipv6 with my vlans on my Ubiquiti stuff. Good
       | luck debugging or calling any tech support when stuff doesn't
       | work, no one understands it heh. Hell even comcast couldn't
       | answer the question as to the delegation subnet size on their
       | provisioned routers (key for deploying more then 1 vlan behind
       | it).
        
       | jlokier wrote:
       | It's 2022 and I've never yet seen an IPv6- _capable_ internet
       | connection at any home I 've lived in, office I've worked at,
       | coffee shop or library whose network I've used. And I've lived in
       | a lot of places
       | 
       | Phones have it. But when I connect my computers via my phone's
       | hotspot, the computers only get IPv4.
       | 
       | My data SIM at home enables IPv6 when used in a phone. But when
       | installed in my 4G router, same contract, same provider, there is
       | no IPv6 despite the router supporting it. That is, supporting in
       | theory. Since I've never seen it enabled, I can't say if it
       | works.
       | 
       | My bare metal servers have IPv6. But my cloud VMs and containers
       | only get IPv4.
       | 
       | The last major network protocol I worked with, a P2P mesh
       | protocol that needs to pass around IP addresses, has IPv6 on the
       | todo list. Last I saw, earlier this year, there was a debate
       | about whether it was worth adding or not. At the moment it's
       | defaulting to no, even though I've seen a few IPv6 addresses
       | attempt to join and be rejected
       | 
       | I can add IPv6 tunnels (VPNs and such) wherever I want, if I want
       | to test software. But I could do that 20 years ago. It feels a
       | bit artifical, not having the real thing.
       | 
       | My current work has a VPN we must use to access work dev servers.
       | Obviously that doesn't use IPv6.
       | 
       | Forget about IPv6-"only", I'm still yet to see much IPv6 at all
       | (except on phones).
        
         | aidenn0 wrote:
         | My experience is quite different from yours:
         | 
         | - my ISP has offered IPv6 /64 delegations for over 5 years now.
         | 
         | - One cloud provider I use gives a discount for VMs with no
         | IPv4 address, the other has ipv6 addresses.
        
       | jedberg wrote:
       | Every couple of months, I enable dual-stack on my home network,
       | to see if it works. And inevitably I get a terrible experience.
       | Some sites fail to load, others load after a huge delay
       | (presumably because we're waiting for an ip6 timeout of some
       | sort) and some things just don't work right. I'm always too lazy
       | to figure out why these things don't work, but I turn off dual
       | stack and everything works fine again.
       | 
       | I'm a network engineer and I can't make ip6 work seamlessly in my
       | house -- what chance do regular consumers have?
        
         | deathanatos wrote:
         | Your experience, and your home network, is absolutely
         | exceptional then.
         | 
         | > _what chance do regular consumers have?_
         | 
         | Clearly, quite a good deal, since dual-stack is the default.
         | Nearly half the Internet[1] is using IPv6 using dual-stack just
         | fine, and the other half is using dual stack with a LL v6
         | because their ISP sucks.
         | 
         | Like many others, my laptop routinely travels, and visits a
         | variety of dual-stack and IPv4 only networks, just as VRBO
         | rentals, cafe WiFi, airports, etc. I've _never_ had an issue
         | connecting to those networks that case caused by dual-stack.
         | Far more often do some form of captive portals (from
         | misconfigured DHCP servers to MitMs wreaking havoc) cause more
         | failures.
         | 
         | > _others load after a huge delay (presumably because we 're
         | waiting for an ip6 timeout of some sort)_
         | 
         | This isn't how v6 works. It isn't impossible that there's
         | _some_ site out there _somewhere_ with a broken AAAA record,
         | but again, it is the exception given the amount of Internet-
         | connected dual stacks. Most v4-only sites aren 't going to
         | _have_ a AAAA.
         | 
         | [1]: https://www.google.com/intl/en/ipv6/statistics.html
        
       | withinboredom wrote:
       | Still no ipv6 support with WSL2 in windows. So, if you're a
       | Microsoft Windows dev in an ipv6 environment, you won't make it
       | too far.
        
         | jeroenhd wrote:
         | Quite a strange limitation in my opinion. I understand that
         | dealing with subnetting/host network rebinding to allow full
         | IPv6 can be a challenge (especially if you're on DHCPv6 or some
         | other manually managed thing instead of normal SLAAC) but
         | surely Microsoft could use whatever NAT solution they use for
         | IPv4 to work on IPv6 as well?
         | 
         | Apparently support for the protocol can already be enabled
         | (https://github.com/nathanchance/WSL2-Linux-Kernel/issues/25).
         | This makes it technically possible to use a WireGuard tunnel
         | for IPv6 support, at least...
        
           | withinboredom wrote:
           | Heh, yeah, I opened that issue. Nathan is awesome for
           | maintaining that kernel.
        
             | jeroenhd wrote:
             | Haha, I didn't even notice. I should clean my glasses!
        
       | maximaximal wrote:
       | We are IPv6-only on our institute-internal CPU compute cluster
       | based on slurm. Only the head node has an IPv4 address, so that
       | it can be reached from IPv4 only clients (sadly, there are still
       | quite a lot). All nodes inside the cluster talk over IPv6. And
       | all other computers with IPv6 access use that to communicate to
       | the head node. We are transitioning to IPv6-only for internal
       | services and try to avoid using IPv4 addresses, only going back
       | to it when something needs to be accessed from the outside.
       | 
       | Sadly, our local ISP is still IPv4-only, meaning we cannot even
       | access our IPv6 hosts while at home, so we need to fall-back to
       | IPv4 quite a lot. Also, the Cisco VPN is still IPv4 only (because
       | of lacking resources to add IPv6 support), so not even the VPN
       | helps. We need to jump over some dual-stack host then.
       | 
       | When speaking to the local ISP, they just reply that it's not
       | planned soon, they don't have resources for it, and "they
       | evaluated IPv6 and don't have a reason to support it". Me/us
       | giving them reasons was not enough it seems.
        
         | jeroenhd wrote:
         | > Sadly, our local ISP is still IPv4-only, meaning we cannot
         | even access our IPv6 hosts while at home, so we need to fall-
         | back to IPv4 quite a lot.
         | 
         | Have you perhaps looked into using tunnels to fix this? he.net
         | can add IPv6 support to any routable IPv4 address that can
         | respond to ICMP. If you need to stick to your internal ULA,
         | something like NPTv6 can translate the /48 subnet HE provides
         | to your own /48 subnet transparently.
         | 
         | Requires some setting up, but so does maintaining VPNs.
        
           | epx wrote:
           | He.net needs a fixed non-CGNAT IPv4 address, with protocol 41
           | open, and this is quite difficult to get.
        
             | jeroenhd wrote:
             | That really depends on where you live. Every ISP I've ever
             | had has fit this bill.
             | 
             | I know IPv4 availability in developing countries is a
             | problem and there's no fix for that other than "wait until
             | IPv6 is available", but in those countries IPv6 is actually
             | part of the solution to not have to rely on "communal" IPv4
             | CG-NAT.
        
           | maximaximal wrote:
           | Yes, I did this on my personal network. I'm in Linz
           | (Austria), the nearest tunnel to a german speaking country
           | that's listed on tunnelbroker.net was Berlin (if I remember
           | right). Everything worked rather well, but I then decided
           | against it, because of the GeoIP implications (with one IP
           | being in Austria and one in Germany) and the added latency.
           | It's noticable when SSHing somewhere whether I'm Linz-Linz or
           | Linz-Berlin-Linz, especially when a small lag spike happens,
           | which is rather frequent with the cable-based network our ISP
           | is offering. It wasn't worth it to half-slowdown our network
           | just to not rely on jumping through some dual-stack node in
           | the university.
           | 
           | If anybody from Liwest (our local ISP) reads this - IPv6
           | would be really nice! :)
        
         | marinesebastian wrote:
         | With all these limitations, why did you prefer IPv6 over IPv4?
        
           | maximaximal wrote:
           | Because we don't want to use 20 IPv4 addresses for the
           | cluster of 20 nodes, when we only have so much addresses
           | assigned to our institute. We could have gone the NAT route,
           | but then we'd need to have some router. And if we designate
           | the head node as router, all traffic would not go through the
           | switch directly, but first through the head node and then
           | out. This would mean that the nodes are less independent, as
           | they have this one additional choke-point. Our university
           | gave us a /64 for this network, so we just used that and it
           | worked flawlessly, also for university-internal distro-
           | package fetching and host-cluster connections.
           | 
           | Also, research software is usually working nicely with IPv6.
           | If we encounter something that would really need IPv4, we
           | could update the thing and give it some local subnet - but
           | currently we were lucky.
        
       | cadence- wrote:
       | I'm still waiting for Amazon to start supporting Elastic IPv6 in
       | their AWS.
        
         | miyuru wrote:
         | You can remove the address(/128) from old instance and assign
         | it in the new instance and it will works just as EIP.
        
         | gurrone wrote:
         | That just made me look at Google Cloud again, and it's
         | depressing to see. At least some types of load balancer do
         | support dual-stack setups, but not if you configure them via
         | GKE with the k8s ingress controller. If you use that one you're
         | out of luck and they maybe now implement it for the new gateway
         | API controller. So if you use GKE and ingress you can configure
         | two of them. One with a static v4 address and another one with
         | a static v6 address. Of course you pay twice then.
        
         | ArchOversight wrote:
         | Why?
         | 
         | What are you using EIP's for and the ability to float them?
        
       | UI_at_80x24 wrote:
       | And this is where government regulation would have helped. It's a
       | shame nobody listened to me back in the 90's: (it's a joke. I'm a
       | nobody, there is nobody listening.)
       | 
       | All cell-phones should have been ipv6 from the get-go.
       | 
       | Now if we could just go back in time and warn everybody about
       | IPv4 address space being exhausted. And maybe the climate too
       | while we are at it.
       | 
       | Seriously though, cell-phone adoption would make that a game
       | changer. Hey Apple, sell it as an exclusive feature!
        
         | bombcar wrote:
         | Cellphones are the main driver of IPv6 adoption as it is; many
         | countries you're behind CGNAT if you hit an IPv4 endpoint, but
         | you go direct if they support IPv6.
        
         | withinboredom wrote:
         | It's not that ipv4 space is exhausted, there's plenty of it
         | available. It's that early on it was mismanaged to the point
         | that people / companies were able to buy entire /8's for
         | basically nothing and hold them forever.
        
           | IcePic wrote:
           | Given the top rate* for handing out ipv4 some 10 years ago,
           | every such "wasted" /8 would give you days to weeks before
           | being used up again. What do you intend to do when those 2
           | weeks are up?
           | 
           | *) https://en.wikipedia.org/wiki/IPv4_address_exhaustion#/med
           | ia...
        
             | noipv6 wrote:
             | the global burn rate was 4-6 weeks for a /8, iirc
             | 
             | but there are waitlists to fulfill, so...you're probably
             | still right.
             | 
             | (tl;dr: "repatriate the poorly allocated legacy ip space"
             | is a losing proposition)
        
               | dang wrote:
               | Single-purpose accounts aren't allowed on HN (they're too
               | predictable and predictability is the antithesis of
               | curiosity) - so I've banned this account. If you don't
               | want it to be banned, you're welcome to email
               | hn@ycombinator.com and we can figure something out.
        
           | gfaster wrote:
           | Related anecdote, my (small) school had acquired a /16 way
           | back and so today, every single device on the network gets
           | its own public ipv4. It was an absolute mess for security
           | (imagine a small army of first year CS majors setting up each
           | a Raspberry Pi) but it was kinda fun being able to experiment
           | with servers without having to worry about NAT.
        
             | mark-wagner wrote:
             | A long, long time ago my (large) school had 2 /16s and a
             | bunch of /24s and every device--including those in the
             | medical center--got a public, internet accessible IP
             | address. https://itconnect.uw.edu/tools-services-
             | support/networks-con...
        
             | ehPReth wrote:
             | they _could_ just firewall inbound connections and have
             | some sort of request /interface to allow certain/all ports
             | whilst keeping everything lovely about public v4 though,
             | yeah?
        
       | dboreham wrote:
       | > The GitHub API and its code load endpoints are not reachable
       | via IPv6
       | 
       | This is quite strange given the period around 2010 where there
       | were government edicts that IPv6 must be supported. Perhaps
       | GitHub wasn't mission critical back then.
        
         | bombcar wrote:
         | There are a number of companies (not naming names) that do NOT
         | support IPv6 for commoners but if you are on a government
         | account/contract you have different government endpoints that
         | ... work over IPv6.
         | 
         | Infuriating, but perhaps understandable; they're willing to
         | support the government over IPv6 because it's required and they
         | pay more. But I wish there was a "I know what I'm doing and
         | understand you'll make fun of me if I ask for support on this"
         | option.
        
           | bryanlarsen wrote:
           | There's probably a ddos service in front of the public facing
           | commercial service that isn't there on the government
           | service.
        
         | rwmj wrote:
         | This seems to be the github ticket / request for IPv6:
         | 
         | https://github.com/community/community/discussions/10539
         | 
         | Apparently github are working on it as of Oct 2022 ...
         | https://twitter.com/AS36459/status/1582728252199964672
        
       | CGamesPlay wrote:
       | To use GitHub on an IPv6-only Hetzner instance, you'll need to
       | use a NAT64 gateway. There's a list of public ones here:
       | https://nat64.xyz/
       | 
       | This can just go into your /etc/hosts:
       | 2a01:4f8:c2c:123f:64::140.82.121.3 github.com www.github.com
        
         | gnfargbl wrote:
         | Huh, so I can effectively use a NAT64 gateway as an
         | unauthenticated open proxy? Let's try it. First look up the
         | IPv4 for a site that reads back your IP address:
         | $ dig +short a icanhazip.com         104.18.115.97
         | 104.18.114.97
         | 
         | (Those are Cloudflare IP; _icanhazip.com_ is hosted on CF.)
         | Next, try connecting to the IP-readback site via a NAT64
         | gateway, but presenting the correct Host header so that
         | Cloudflare knows what to do with the request:
         | $ curl -6 -k -H 'Host: icanhazip.com'
         | https://[2001:67c:2960:6464::104.18.115.97]/
         | 141.98.136.43
         | 
         | OK, it reads back an IPv4...                   $ dig +short -x
         | 141.98.136.43         de-fra2-nat641.level66.network.
         | 
         | ...with a PTR record associated with level66.network, which was
         | the NAT64 gateway we chose.
         | 
         | How does this not see more abuse by bad actors? I guess it
         | probably does, which is why there are so few of these public
         | gateways?
        
           | jeroenhd wrote:
           | > How does this not see more abuse by bad actors?
           | 
           | Because this tech goes unused in almost all cases. Also
           | doesn't work if your DNS client is secure against tampering
           | (i.e. uses DNSSEC) without more configuration.
           | 
           | To make this work, you need to intercept and modify the
           | victim's DNS traffic or reconfigure the victim's DNS server
           | somehow. With that amount of control, IPv6 or IPv4 no longer
           | matter; you apparently have full network or configuration
           | access already.
           | 
           | There are protocols to automatically configure such
           | workarounds intended for ISPs, but I don't think they see
           | much use.
           | 
           | > which is why there are so few of these public gateways?
           | 
           | I think a bigger problem is that you're piping a lot of
           | people's internet traffic through your own network for...
           | fun, I guess? To make this sustainable you need a business
           | model and I don't see why anyone would pay for such a service
           | until IPv6-only hosts start becoming more common.
        
             | russdill wrote:
             | Ugh, I was under really looking forward to trying out NAT64
             | one day. Potential complications with DNSSEC never occurred
             | to me. Thanks for the reality check.
        
         | 9dev wrote:
         | That's what I ended up doing, but it's a major turn-off to
         | learn this by trial and error, after setup scripts fail with
         | seemingly unrelated messages.
        
           | CGamesPlay wrote:
           | Yeah, if any Hetzner reps are reading this thread, it would
           | be great to put up a support page talking about NAT64, and
           | link to it from the dashboard when creating IPv6-only
           | instances.
        
             | ddalex wrote:
             | And if any Github reps are reading this thread, put
             | together a presence on IPv6. If Google can do it, so can
             | Microsoft.
        
       | ufmace wrote:
       | I was rather dissuaded from trying to keep it working on any of
       | my servers when, after much head-scratching and wrangling, I
       | eventually traced a bunch of weird network issues on my desktop
       | system to IPv6. Seems that any web requests to sites that
       | supported v6 natively were randomly flaky and slow, causing
       | terrible video streaming performance. Only fixed when I shut off
       | v6 at the network adapter level.
       | 
       | Guess I'll try and turn it back on in a year or two and see if
       | it's still terrible. If it's not, maybe I'll think about turning
       | it on for some of my servers again.
        
       | nikanj wrote:
       | I can trivially remember a bunch of ipv4 addressed, and recognize
       | them at a glance ("oh that's just our office vpn endpoint, that
       | traffic is benign"). No hope of that with ipv6.
        
         | ju-st wrote:
         | If your office has a /48 you could surely memorize the subnet
         | itself and/or give your important endpoint the shortest
         | possible IP address like: 2001:db8:a0b0::1 or even something
         | funny like 2001:db8:a0b0::0ff1:ce
        
           | Dagger2 wrote:
           | Yeah, just pick <prefix>::200 instead of <WAN IP>+<RFC
           | 1918>.200. Forget "no hope", that actually looks easier than
           | the v4 case to me... especially if you have any RFC1918
           | clashes going on, which many companies do.
        
       | telmich wrote:
       | We are running a lot of IPv6 only clusters and don't have any
       | issues. The key solution is to have a NAT64 gateway somewhere at
       | the edge.
        
       | a-dub wrote:
       | they don't offer free private ipv4 with nat?
       | 
       | these are all outbound reachability issues. the bigger concern
       | i'd have would be inbound reachability for public services.
       | 
       | you don't need routable ipv4 addresses on every host to hit
       | public ipv4 internet services!
        
       | gurrone wrote:
       | 20 years ago it was the lack of IPv6 support on the CPE holding
       | IPv6 on the server side back, nowadays it's a lack of IPv6 at
       | major SaaS providers causing issues. In most of the scenarios I
       | was involved in we made sure that the CDN in front of the product
       | was able to terminate IPv6 and left everything behind it v4 only.
       | About 1/3 to 1/2 of the traffic received was sent via IPv6 on
       | those setups. Maybe time to turn that around and use the CDN to
       | make the product also available via v4? Leaves you with
       | maintaining a NAT gateway for your own infrastructure.
       | 
       | BTW also only one of the office networks I had to deal with in
       | the past 20 years hat experimental IPv6 support, and that was at
       | a small local hosting company. Everything bigger than that also
       | sticks to IPv4 only for now. :(
       | 
       | Strange how things change but still stay the same.
        
       | RijilV wrote:
       | It's been a quarter of a century since IPv6 launch.
       | 
       | There's some really good lessons learned here. IPv6 requires
       | everyone, everywhere, needs to change their configuration to add
       | IPv6 addresses and network connectivity to every node/endpoint.
       | The madness of course is that all the underlying infrastructure
       | software (routers, OS, standard libraries) all support IPv6. It
       | would seem, at a large enough scale, that software is the easy
       | part, configuration is the hard part.
       | 
       | DJB wrote this up two decades ago[0] and it remains relevant. In
       | particular the comparison between IPv6 and MX records. It took me
       | a little while to wrap my brain around just extending existing
       | software to support sometimes 32bit and sometimes 128. Ultimately
       | it wasn't hard to dream up a few solutions for how that would
       | work.
       | 
       | The other thing, FWIW, which has been slowing IPv6 adoption is
       | business owners not asking for it as a high priority item from
       | their providers. I've seen this happen way more often that I
       | would like where provider asks a customer what they want and the
       | customer never mentions IPv6, and when prompted shrugs it off
       | because they don't see it as a business critical (and in
       | fairness, it hasn't been). Yes provider isn't asking the 'nerds'
       | at their customer's businesses, but those folks also aren't the
       | ones paying the bills so...
       | 
       | 0: https://cr.yp.to/djbdns/ipv6mess.html
        
         | connicpu wrote:
         | I got a brand new router recently, IPv6 was still disabled by
         | default! I honestly can't understand the reasoning, I don't
         | even buy the internet visibility argument because the default
         | incoming connection rules for IPv6 after I enabled it were
         | deny-all. We really have a long way to go still in getting
         | equipment everywhere enabled on it.
        
         | noipv6 wrote:
         | anyone who thinks "ipv6mess" is still relevant in 2022, doesn't
         | understand the problem space it describes.
         | 
         | part 1, interoperability failure/incompatibility: nat64+dns64
         | has been viable since 2008
         | 
         | part 2, incoherence: dual-stack was the transition plan, & was
         | clearly communicated from the start (to anyone who listened).
         | that turned out to not be so effective since so many ppl
         | ignored the realities of legacy ip depletion. at this juncture
         | ipv6-only (w/ nat64) is becoming a more preferable approach,
         | since you only need to maintain a single protocol in the
         | majority of your environment (as evidenced by org's like
         | tmobile us, facebook, etc).
         | 
         | part 3, distractions: one could argue that rants like
         | "ipv6mess" are the biggest distractions to ipv6 deployment.
         | 
         | "no one is asking for ipv6" is a lie writ large in the provider
         | space; i've seen plenty of examples where a provider has told
         | multiple customers "you're the first person to ask for ipv6
         | support!" - the problem being is that most org's don't actually
         | keep track of such requests in a unified place, & so every
         | customer is pushing for it alone, so far as the provider is
         | concerned.
        
           | cryptonector wrote:
           | > anyone who thinks "ipv6mess" is still relevant in 2022,
           | doesn't understand the problem space it describes.
           | 
           | It was relevant then -and it is relevant now- because there
           | are good lessons in how to migrate from thing A to thing B,
           | even if some of the then-missing necessary bits are in place
           | now.
           | 
           | Still, it's almost certainly the case that DJB's rant had no
           | real effect, and that the necessary steps were bound to be
           | taken as the cost of sticking with IPv4 rose. Also, a
           | significant period of time was always going to be necessary
           | for software and tooling to catch up -- perhaps there wasn't
           | much to be done about improving the transition 20 years ago.
           | Yet DJB's rant isn't wrong or devoid of value -- it's mostly
           | right and entertaining (still!), even if there just wasn't
           | enough IETF and dev oomph to do better at the time.
        
             | noipv6 wrote:
             | > It was relevant then -and it is relevant now- because
             | there are good lessons in how to migrate from thing A to
             | thing B, even if some of the then-missing necessary bits
             | are in place now.
             | 
             | it's irrelevant now because there are smoother approaches
             | to migrating to future-proofed networks than existed at the
             | time. the fact that it persists on the internet, unamended,
             | to be regularly presented (two decades later) as some
             | semblance of current realities of the challenges to ipv6
             | deployment is a disservice to the internet.
             | 
             | > Still, it's almost certainly the case that DJB's rant had
             | no real effect, and that the necessary steps were bound to
             | be taken as the cost of sticking with IPv4 rose.
             | 
             | i would maintain that "ipv6mess" had a NEGATIVE impact on
             | ipv6 adoption overall, as people who saw djb as a tech god
             | accepted his word as gospel, despite it fundamentally being
             | a crybaby rant, & proliferated the misconceptions &
             | opposition therein.
             | 
             | the fact that he explicitly rejected ipv6 patches to qmail
             | & djbdns (resulting in a fork to at least qmail) should not
             | be understated - he didn't just complain about ipv6, he
             | actively sought to undermine its adoption.
        
             | Dagger2 wrote:
             | I'm not sure it was ever relevant. All it does is describe
             | the problem, which was already well-known at the time by
             | the people working on v6. It doesn't give a fix for it.
             | 
             | It doesn't give a fix because no fix is possible. Because
             | the problem comes from the design of v4, not from v6.
             | 
             | For some reason djb wasn't able to get his head around
             | that, and people have been pointing to that damn page as if
             | it's some big gotcha ever since. No, it's just the
             | situation we're stuck with, thanks to the people that
             | designed v4.
        
               | howinteresting wrote:
               | I mean, v6 is still mostly a failure, so (rightly or not)
               | the situation is going to be blamed on the people that
               | have been pushing v6. That's just the cost of trying to
               | push the entire world towards a new standard.
               | 
               | (I know that v6 has been a success within datacenters and
               | such.)
        
               | noipv6 wrote:
               | by what definition would you call ipv6 "mostly a
               | failure"? 30-40% global eyeball network (to the end user)
               | adoption after ~10 years of active deployment, against
               | very vocal opposition seems commendable enough to me.
        
               | mort96 wrote:
               | If it describes problems we're still struggling with,
               | it's still relevant.
        
               | cryptonector wrote:
               | It talks quite a bit about how to tackle migrations. It
               | doesn't specify specific solutions for IPv6, no, but it
               | does talk about what doesn't work and what should be
               | looked into. It's a blog, not an Internet-Draft.
        
           | MisterTea wrote:
           | > part 1, interoperability failure/incompatibility:
           | nat64+dns64 has been viable since 2008
           | 
           | Why are we stuck with nat in 2022 again? Why did we not map
           | the 32 bits of ipv4 to ipv6?
           | 
           | > part 2, incoherence: dual-stack was the transition plan, &
           | was clearly communicated from the start (to anyone who
           | listened).
           | 
           | Perhaps they didn't listen because dual stack means investing
           | in building another incompatible internet on ipv6 in parallel
           | with the ALREADY WORKING ipv4 internet. Reminds me of a great
           | quote: "the most dangerous enemy of a better solution is an
           | existing codebase that is just good enough." - Eric S Raymond
           | 
           | > part 3, distractions: one could argue that rants like
           | "ipv6mess" are the biggest distractions to ipv6 deployment.
           | 
           | Because it is a mess. Stop denying that. If ipv6 was designed
           | to be easily deployed via backwards compatibility then we
           | would be using ipv6 already.
        
             | Sesse__ wrote:
             | > Why are we stuck with nat in 2022 again? Why did we not
             | map the 32 bits of ipv4 to ipv6?
             | 
             | Because it does not help. djb's "idea" was to change
             | everybody's setup _first_ and then have a flag day where
             | the entire world were moved from IPv4 to IPv6 in one big
             | change. Good luck with that. (And only after that flag day,
             | we could start actually using a larger address space to try
             | to get rid of NATs.)
             | 
             | The ipv6mess essay is confused because it somehow thinks
             | _getting addresses_ is the hard problem. It does not solve
             | _any_ other configuration or coding part. You still need to
             | upgrade DNS. You still need to have a different wire
             | protocol. You still need every hop on the path from me to
             | you to understand and route IPv6.
             | 
             | At least now with gradual rollout and dual stack, we're at
             | 40% of endpoints and AFAIK a majority of traffic. With
             | djb's plan, we'd still be at zero.
        
             | throw0101a wrote:
             | > _Why are we stuck with nat in 2022 again? Why did we not
             | map the 32 bits of ipv4 to ipv6?_
             | 
             | Oh, you mean like this:
             | 
             | > _Addresses in this group consist of an 80-bit prefix of
             | zeros, the next 16 bits are ones, and the remaining, least-
             | significant 32 bits contain the IPv4 address. For example,
             | ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128.
             | A previous format, called "IPv4-compatible IPv6 address",
             | was ::192.0.2.128; however, this method is deprecated.[61]_
             | 
             | * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addre
             | sse...
             | 
             | *
             | https://datatracker.ietf.org/doc/html/rfc4291#section-2-5-5
             | 
             | You _still_ need to upgrade bit of networking kit between
             | the source and destination to understand  "IPv4+", and this
             | (lack of) upgrading and enabling is what is hampering
             | deployment.
             | 
             | What makes you think that companies would have been willing
             | to make the effort to deploy "IPv4+" any more than IPv6?
             | 
             | > _Because it is a mess. Stop denying that. If ipv6 was
             | designed to be easily deployed via backwards compatibility
             | then we would be using ipv6 already._
             | 
             | Backwards compatibile IPv6 was impossible.
             | 
             | IPv4 has 32 bits of address. Anything after IPv4 needed >32
             | bits of address. How do you fit in >32b in a data structure
             | that is 32b? You cannot.
             | 
             | So you have to go an replace every bit of networking code
             | out there to change the data structures. You know, like was
             | done to deploy IPv6.
        
         | xattt wrote:
         | If we take a chapter on fixing broken implementations from the
         | USB Forum, the clear solution is to come up with an IPv6 Rev.
         | e^76.
        
       | exabrial wrote:
       | ipv6 would be completely unnecessary. Only a handful of things on
       | the internet actually need to be publicly addressable. Even
       | something as simple as SRV record support in browsers would solve
       | 99% of the invented ipv4 "crisis". Furthermore if people could
       | come up with actual technical reasons why NAT is bad, rather than
       | "I don't like it"... because guess what? It's here, it's now, and
       | it's been working just fine for 30+ years.
       | 
       | That being said ipv6 offers some really nice features around
       | flow-ids and getting rid of dumb and dangerous ipv4 flags. Credit
       | is due where credit is due and these debugging features of ipv6
       | are worth mentioning as they really did get it right.
       | 
       | Despite this, in my opinion, we simply don't have a use case for
       | ipv6. ipv4 + NAT + BGP (and maybe some SRV records) is all
       | humanity needs, forever.
       | 
       | I will continue to disable ipv6 on all the networks and devices I
       | manage, as it's an unnecessary and useless attack surface that
       | ultimately offers me 0 benefit, just downsides.
        
         | zekica wrote:
         | NAT is not working fine. Have you ever needed to set up STUN +
         | TURN?
        
           | deathanatos wrote:
           | I think many people are oblivious to STUN/TURN, and the
           | amount it happens in alleged "peer-to-peer" stuff like
           | <insert "Show HN: I built X on top of WebRTC" article here>.
           | 
           | Or setting up port-forwarding. Or having to deal with
           | "hairpin NAT". Or having to deal with trying to route two
           | networks together over VPN without having their address
           | spaces collide because literally everyone uses the low end of
           | 10/8. Or the amount of money being siphoned off for the
           | privilege of having an IPv4 address.
        
       | LinuxBender wrote:
       | I have not seen a practical way to go IPv6-Only. If I made my
       | DNS, Web, Chat, Time and other servers IPv6-Only I would only be
       | able to access them from a few mobile networks, most VPS
       | providers and a handful of ISP's. One might be tricked into
       | thinking adoption is high, but the VPS and mobile providers
       | really throw off the statistics. Mobile providers due to sheer
       | numbers of clients and being late to the allocation game did not
       | have much choice but to go IPv6 and set up IPv4 gateways/tunnels.
       | 
       | I could see doing IPv6+IPv4 in a corporation and terminate
       | everything on load balancers, allowing anything behind the LB to
       | be any combination of IPv4/IPv6. But IPv6 only? I don't see any
       | big companies doing that in my lifetime.
       | 
       | My ISP obtained some IPv6 space but have not deployed it yet as
       | they are still trying to decide how to subnet and bill for it so
       | I currently have some static IPv4 addresses. I am on a tiny ISP,
       | so tiny all their C-Levels phone numbers and email addresses are
       | still in whois. Most of the US ISP's doing IPv6 also do IPv4 even
       | if sometimes it is CG-Nat.
        
         | noipv6 wrote:
         | > I could see doing IPv6+IPv4 in a corporation and terminate
         | everything on load balancers, allowing anything behind the LB
         | to be any combination of IPv4/IPv6. But IPv6 only? I don't see
         | any big companies doing that in my lifetime.
         | 
         | facebook started migrating to ipv6-only datacenters in 2014 or
         | so. i think all of them are converted at this point. they only
         | support legacy ip at their network edge, & use siit (iirc) to
         | facilitate access.
        
           | LinuxBender wrote:
           | The legacy IP at their edge is what I meant by terminating
           | IPv4+IPv6 at the load balancers.
           | 
           | The tricky part is that almost all datacenters today need to
           | talk out to other datacenters. Not all of them use IPv6 which
           | means they will still need some way to speak IPv4 until all
           | their 3rd party data processors are also doing IPv6 and for
           | Facebook I happen to know that is a lot of 3rd parties. If
           | they are truly IPv6-only in the datacenter then they would
           | have to forward-proxy all outbound connections through
           | something with an IPv4 address on the edge as well and that
           | can not go away until all their partners and vendors are also
           | purely IPv6.
        
             | Dagger2 wrote:
             | You can do that with NAT64, which you can run as a service
             | in your datacenter rather than needing to deal with v4
             | throughout it. (In fact it doesn't have to be run in your
             | datacenter -- it could be outsourced to somebody else,
             | which will probably make sense eventually as v4 use
             | dwindles.)
        
       | MindTooth wrote:
       | In Norway, it's required[0] for all public sectors to have IPv6.
       | We are not there yet, but I believe the push will only increase
       | with time.
       | 
       | Especially all new internal networks must be IPv6, and IPv4 is
       | optional.
       | 
       | [0]:
       | https://lovdata.no/dokument/SF/forskrift/2013-04-05-959?q=ip...
       | (Sorry that it's in Norwegian.)
        
         | AdrianB1 wrote:
         | Norway is not big enough on Internet scale to make a
         | difference. Equipment and software companies will put in
         | balance the cost vs the benefit and may decide to ignore that
         | market.
        
           | Dagger2 wrote:
           | Perhaps not by themselves, but every country that does this
           | adds to the weight of the argument.
        
         | sybercecurity wrote:
         | There is a current effort to fully transition the US government
         | internal networks to IPv6 only:
         | https://www.gsa.gov/technology/technology-products-services/...
         | 
         | Considering how many old, IPv4 based management and security
         | tools are probably in use, it will be an exciting time.
        
       | nathanaldensr wrote:
       | I disabled IPv6 on my home network completely because it
       | interferes with my use of my Raspberry Pi as a DNS blocker. I was
       | never able to get DNS working properly, which, apparently, is
       | intentional with regards to the IPv6 protocol.
       | 
       | Meh.
        
         | Dagger2 wrote:
         | It definitely doesn't do any of that.
         | 
         | Your problem was having a non-Pi-hole DNS server configured. If
         | you want to run all of your DNS queries through Pi-hole, don't
         | configure a DNS server that's not the Pi-hole server (or which
         | doesn't forward its queries to it).
        
         | jeroenhd wrote:
         | It's not supposed to. My pihole blocks IPv6 just fine, whether
         | it's being reached from an IPv4 or an IPv6 address. IPv6 has
         | very little to do with DNS.
        
       | Yuyudo_Comiketo wrote:
       | All ipv6 shortcomings discussion aside; What I think is the more
       | vital problem to focus on is that the governments clearly don't
       | want us mere mortals to expose our own servers running on our own
       | hardware to the outside world (most often justifying that with
       | "it's for your own security" mantra, for we're all deemed too
       | dumb to figure that out for ourselves).
       | 
       | ISP-imposed ipv4 double NAT (imposed on ISPs by the governments,
       | I am pretty sure about that) reduces our devices to all but dumb
       | receivers which are scarcely superior to TV sets. And no amount
       | of STUNning and TURNing, or buying VPSes can realistically fix
       | this situation, when we can't simply connect our devices directly
       | without resorting to some service provided by some Men in the
       | Middle. And it gets worse, 10 years ago I could buy a static
       | public IP from my ISP for some affordable extra - all ports open
       | unless blocked manually in my firewall - nowadays there remain no
       | ISP around to sell those to the general public. Just no such
       | option anymore. Too much freedom it gave, I guess.
       | 
       | So this begs the question: can ipv6 fix that? Will ipv6 fix that?
       | I'm afraid not.
        
         | Dagger2 wrote:
         | CGNAT isn't imposed by governments, it's imposed by address
         | space exhaustion in v4. v6 fixes it by having enough address
         | space that NAT isn't needed.
         | 
         | Governments share some responsibility here for not mandating a
         | move to v6, leaving everybody in "wait for other people to go
         | first" mode, and one might ask why they've done that but the
         | answer is mostly that governments don't usually get involved in
         | the Internet at that level.
         | 
         | I've not seen an ISP do CGNAT on v6, even when they're doing
         | CGNAT on v4. This makes sense because CGNAT is expensive and
         | doesn't have any benefits for the ISP except for dealing with
         | address space exhaustion. If they wanted to prevent inbound
         | connections then all they would need to do is firewall them.
        
         | Klonoar wrote:
         | Can you provide a source for that government claim?
        
           | Yuyudo_Comiketo wrote:
           | - Comment sections getting closed for anonymous replies
           | almost everywhere over the course of the last 15 years
           | 
           | - Undisguised surveillance becoming the new normal
           | 
           | - Confinement of all communication to a handful of platforms
           | 
           | - Snowden's disclosures
           | 
           | - Huge datacenters built by NSA to tap into telecom
           | 
           | - Crackdown on p2p sharing
           | 
           | - Push for The Cloud
           | 
           | - Closure of Lavabit and other independent email providers
           | 
           | - Rabid push for phone-based 2fa
           | 
           | - Ongoing merger and conglomeration of everything into a
           | venture-fund-owned megacorporation invisible only for those
           | who call these obvious practices "conspiracy theories" with
           | religious zeal
           | 
           | - Failure of everything initially claimed to be
           | decentrallized to live up the name, including blockchains,
           | IPFS etc
           | 
           | These and many other similar issues combined don't quite make
           | for an illusion that the govenments are willing to allow us
           | to communicate freely via a greater number of tapping and
           | datamining points than they could possibly manage.
           | 
           | Now burn this heretic!
        
             | Klonoar wrote:
             | Sigh, I need to stop engaging with obvious tinfoil hats.
        
               | Yuyudo_Comiketo wrote:
               | Oh boy, all my points are definitely beaten with this
               | single one of ineffable precision and efficiency!
               | 
               | What you need is to learn to reinforce your opinion with
               | counterarguments instead of allegorically admitting your
               | inability to formulate them.
        
         | acdha wrote:
         | This seems like a poorly-researched conspiracy theory. Nobody
         | is forced to use double-NAT, and if there was some secret
         | policy which somehow has avoided leaking for a couple of
         | decades, you'd think they'd have blocked IPv6 deployments, too.
        
           | Yuyudo_Comiketo wrote:
           | I expected that someone would plant this prefabricated gag
           | phrase of "conspiracy theory" as an argument, thanks for
           | confirming my gut feeling.
        
         | yyyk wrote:
         | Your theory is contrary to what happened in reality: It was
         | governments mandating router and OS support of IPv6 that jump-
         | started protocol support. Had the mandate not existed, MS would
         | not have added IPv6 as early as Win XP (in preview during Win
         | 2000).
        
       | buildbuildbuild wrote:
       | This problem led us to self-hosting Gitlab four years ago, I
       | can't believe it's still an issue in 2022.
       | 
       | It's appalling that a "developer product" like Github remains
       | such a blocker to IPv6 adoption, especially for highly Github-
       | reliant communities like the Golang ecosystem.
       | 
       | Launch an IPv6-only VM and try to build a mainstream Go project.
        
         | mappu wrote:
         | Most of Go dependencies these days come from your $GOPROXY,
         | which by default (proxy.golang.org) is available over IPv6 just
         | fine.
        
       | can16358p wrote:
       | My whole country of 80 million people with very high Internet
       | usage is still not supporting IPv6 at all (and residential
       | connections are behind CGNAT). I'm pretty sure there are many
       | more. IPv6 might be a thing in US or Europe, but definitely not
       | in the world.
        
         | scarmig wrote:
         | IPv6 penetration:                 1. France   72.63%       2.
         | India    66.47%       3. Germany  65.45%       4. Greece
         | 62.13%       5. Malaysia 60.03%       ...       15. United Arab
         | Emirates  48.69%       16. United States         47.99%
        
         | noipv6 wrote:
         | is "not supporting IPv6 at all" a data-backed statement?
         | 
         | https://stats.labs.apnic.net/ipv6/ fwiw
        
           | jeroenhd wrote:
           | Going by the "80 million" comment and the map you've linked,
           | the countries that come closest are Germany (+-60%), Iran
           | (0.34%), and Turkey (1.79%).
           | 
           | Iran has an oppressive government with severe internet
           | restrictions, so I'm not surprised they're not making IPv6 a
           | priority. I'd assume their traffic interception devices don't
           | work all that well without IPv4, they never seem to.
           | 
           | With 1.79% being IPv6 capable (not even configured), I'd say
           | availability is effectively 0%. It's technically 2%, but I'd
           | imagine those 2% are mostly hosting services and such.
           | 
           | Reverse sort the availability table and lots of countries
           | have availability below even 5%. Nigeria, the 7th most
           | populated country in the world, is at 0.38%. Lithuania, part
           | of the EU and its economic bloc, is at 0.16%.
        
       | api wrote:
       | The biggest problem remains cloud and CDN companies with poor to
       | nonexistent IPv6 support. Most ISPs, especially on mobile, have
       | it now or are adding it very soon.
       | 
       | I've wondered whether some might be dragging their feet because
       | they see an advantage in IP address scarcity to sell cloud
       | gateways, CDNs, and other middle box type services. But the most
       | likely explanation remains that not enough customers are asking
       | for it so it's not the highest priority.
       | 
       | I happen to know that Google Cloud started moving on IPv6
       | seriously only when they lost some big telecom customers to AWS
       | because they didn't have it.
        
         | dboreham wrote:
         | > Most ISPs, especially on mobile, have it now or are adding it
         | very soon.
         | 
         | Except Charter/Spectrum in the US.
        
           | 2000UltraDeluxe wrote:
           | Telia in Finland refuses to enable IPv6 for mobile. I'm sure
           | there's no lack of providers doing the same.
        
           | mindcrime wrote:
           | I'm on Spectrum (via TW acquisition) and have had IPv6 for
           | around a decade, if not longer.
        
           | api wrote:
           | I have it on Spectrum in Ohio. It may vary by market.
        
           | trynewideas wrote:
           | https://www.spectrum.net/support/internet/ipv6-faq:
           | 
           | > IPv6 is available today with an IPv6 capable modem in the
           | majority of Spectrum's footprint.
           | 
           | Very curious what "majority of Spectrum's footprint" means in
           | this context.
        
           | JshWright wrote:
           | Maybe it's because we're in the former Time Warner Cable/Road
           | Runner part of Spectrum's territory, but we've had IPv6 for
           | years now.
        
             | cloudwalk9 wrote:
             | I'm in original Charter territory and have v6
        
             | AnIdiotOnTheNet wrote:
             | Sure, as long as you're ok with having a constantly
             | changing prefix. At least that's how it is for home
             | connections and it nullifies nearly all the benefits of v6.
        
               | Dagger2 wrote:
               | You don't need a fixed prefix to get most of the benefits
               | of v6.
               | 
               | DNS is a thing.
        
               | AnIdiotOnTheNet wrote:
               | I can do dynamic DNS on v4 too.
               | 
               | It also complicates firewalls, because now they need to
               | deal with the prefix switching on them and updating their
               | rules to match. As I recall this was only recently added
               | to pfSense.
        
         | mort96 wrote:
         | I've never been on a non-mobile connection with IPv6. It's not
         | a thing in Norway.
        
           | noipv6 wrote:
           | is the 22+% ipv6 adoption in .no all mobile? (honest question
           | - i don't know)
           | 
           | https://stats.labs.apnic.net/ipv6/NO
        
       | cletus wrote:
       | IPv6 is a case study in the second sytem effect [1]. Realizing
       | you need to make breaking changes and it being rare that you get
       | to do so you decide to make _all_ the changes.
       | 
       | The truth is IPv4 only had 2 real problems:
       | 
       | 1. Lack of address space due to 32 bit addresses; and
       | 
       | 2. Lack of a solution for roaming since your IP address is a core
       | part of connection identity (between the source and destination
       | address and port).
       | 
       | IPv6 managed to only solve one of these problems and it did so in
       | a way that _removed_ functionality. Yes there are more addresses
       | but now address blocks are non-portable. I guess 25 years ago
       | they thought that routing protocols like BGP4 were considered a
       | problem and decided to remove that with hierarchical address
       | spaces and massively expanded those address spaces to do it.
       | 
       | Somehow ports were also considered a problem so we got /64
       | addresses. Part of the motivation for this was to use (mostly)
       | unique MAC addresses (48 bits) as your identifier and that fits
       | in 64 bits. Of course this became a massive PII leak and a
       | tracker's dream so it never happened but we're still stuck with
       | /64 blocks that we absoultely do not need.
       | 
       | It's an object lesson in solving actual problems and not solving
       | imagined problems.
       | 
       | [1]: https://en.wikipedia.org/wiki/Second-system_effect
        
         | fulafel wrote:
         | You can get PI v6 space, and if you are somewhere where a RIR
         | won't give it to you, that's not the protocol's fault.
         | 
         | Also ports weren't removed, they work just like in v4.
         | 
         | The long addresses with subnettable space for everyone is very
         | valuable and useful and doesn't remove any functionality.
        
         | cryptonector wrote:
         | Finally, a great comment in this thread.
         | 
         | Arguably lack of IP address block portability is not that big a
         | deal [now that we're well used to it]. But IPv6 did not solve
         | the CIDR route table size issues, and that's a big failure.
         | 
         | I have long thought that IP packets should have a source and
         | destination ASNs as well as actual addresses. That would mean
         | that we'd need more DNS (or similar) lookups, and a
         | bootstrapping system for that. A scheme like this would greatly
         | reduce router table sizes and would allow for IP address block
         | portability.
        
         | noipv6 wrote:
         | > Part of the motivation for this was to use (mostly) unique
         | MAC addresses (48 bits) as your identifier and that fits in 64
         | bits. Of course this became a massive PII leak and a tracker's
         | dream so it never happened but we're still stuck with /64
         | blocks that we absoultely do not need.
         | 
         | please read about rfc4941 privacy extensions & how prevalent
         | their use is before continuing to regurgitate decade-old,
         | outdated privacy alarmism about MaC aDdReSsEs.
        
       | [deleted]
        
       | bravetraveler wrote:
       | Indeed, I've had similar difficulties... and my needs are rather
       | low! Basically get to the distribution-provided repositories.
       | 
       | This doesn't reliably work. If I get lucky and get a mirror with
       | AAAA, all's well. If not, I may get stuck in an annoying retry
       | loop.
       | 
       | I resorted to making a dumb router VM. It has v4 that everything
       | else uses to route public traffic through
        
       | 0xbadcafebee wrote:
       | The industry doesn't give a shit. Everyone follows the path of
       | least resistance, which is: don't change, apply crappy hacks, try
       | to prevent any work you don't want to do. IPv6 was never going to
       | be adopted quickly because nobody was forced to.
        
       | justin_oaks wrote:
       | Having "grown up" with IPv4, I'm slow to learn everything
       | necessary to set up an IPv6 infrastructure. The times I did look
       | into it, IPv6 seemed so much more complicated than IPv4, but
       | maybe that's just because I'm just not familiar with it.
       | 
       | Are there any good resources on setting up IPv6 support from
       | first principles?
       | 
       | I still get confused as to the "right" way to set up internal
       | networks for IPv6, especially when DHCPv6 isn't universally
       | supported (I'm looking at you Android).
        
         | AdrianB1 wrote:
         | Growing up implementing IPv4, then moving to a different part
         | of IT, I never found a reason to learn IPv6; it is something
         | that is out there, but not relevant for me. I cannot tell if
         | this good or bad.
        
         | yesco wrote:
         | A confusing aspect of IPv6 is that it's actually a much simpler
         | protocol than IPv4, you often end up assuming you need to
         | configure a bunch of stuff that you really don't have to.
         | 
         | The most common example would be NAT, despite the complexity it
         | adds to IPv4, people often get comfortable with idea of setting
         | up complex subnet hierarchies and feel lost when that all just
         | disappears with IPv6.
         | 
         | The key things to remember when working with IPv6 are:
         | 
         | - IPv6 is very unidirectional, it's not a giant one way
         | waterfall like IPv4/NAT
         | 
         | - Routers don't assign addresses, they advertise "prefixes",
         | usually multiple
         | 
         | - Routers will usually have a prefix for: Internet, WAN, Link-
         | Local (last one being advertised only to nodes directly
         | connected to it)
         | 
         | - Nodes use prefixes to auto-generate an address
         | 
         | - Auto generated addresses are usually in the form of "prefix -
         | device_id" so even if a node has a lot of addresses, they are
         | all mostly the same
         | 
         | - Usually nodes can easily communicate back and forth across
         | multiple local routers with little configuration or hierarchy
         | 
         | - Internet/non-local IPv6 addresses break the rules a bit and
         | don't use a device_id in their addresses in order to protect
         | user privacy
         | 
         | - Even if every node has an external address now, you can still
         | configure your firewall to ensure they are isolated from
         | external connections (which is usually the default anyway). You
         | don't need NAT to securely isolate things.
         | 
         | - Once you get the hang of it you will realize how easy it
         | makes everything and despair that support for it sucks and
         | everyone makes it harder than they need to
         | 
         | Finally for learning resources I honestly recommend just
         | reading the RFCs, I personally learned this way and believe
         | they provide the most direct understanding of the rational
         | behind everything.
        
           | b1zguy wrote:
           | Thanks for the insightful primer!
        
           | therealmocker wrote:
           | One thing I wish they had done with the much larger address
           | space is make it easy for an individual to get their own
           | block of IPv6 addresses. Letting enthusiasts experiment with
           | their own address space seems like it would help with
           | knowledge / adoption.
        
             | FateOfNations wrote:
             | Big evil Comcast gives out a /60 to residential customers
             | if you ask for it (via setting a DHCP option). That allows
             | for 16 networks to work with.
        
               | akira2501 wrote:
               | DHCPv6 Prefix Delegation. If you're a business customer,
               | you get a larger allocation seemingly depending on the
               | size of your IPv4 static block. I've been given /56 and
               | /54 from their business service. It's quite nice.
        
           | justin_oaks wrote:
           | Thanks, that helps a lot.
           | 
           | This got me reading about IPv6 again. I'm trying to figure
           | out how we'd set up an IPv6 network in the case where we have
           | 1) Two upstream ISPs, mostly for failover, but could be
           | loadbalanced too. 2) Internal servers with assigned DNS
           | 
           | My initial thoughts were that for each of the two ISPs, each
           | host (e.g. personal desktop or laptop) would use the IPv6
           | prefix and end up with two addresses. But in the interest of
           | having an internal address for internal servers, we'd need
           | yet another IPv6 prefix for internal use. That makes 3 IPv6
           | addresses per host.
           | 
           | Does that make sense? I read about getting Provider
           | Independent (PI) address prefixes, which would allow use to
           | consolidate to a single IPv6 prefix, but from what I read,
           | that costs money and should generally be used for large
           | organizations. Ugh.
        
             | Arnavion wrote:
             | If you want failover-independent IPs you can keep using
             | NAT, ie NPTv6, at the gateway level and not bother with
             | giving public IPs to your LAN machines.
        
           | nottorp wrote:
           | Ok, i'll bite.
           | 
           | > Auto generated addresses are usually in the form of "prefix
           | - device_id" so even if a node has a lot of addresses, they
           | are all mostly the same
           | 
           | > Internet/non-local IPv6 addresses break the rules a bit and
           | don't use a device_id in their addresses in order to protect
           | user privacy
           | 
           | So a device needs to have both an internal address and an
           | "Internet/non-local" address in IPv6?
           | 
           | Plus one for WAN and Link-Local?
           | 
           | 4-5 addresses per device?
        
             | FateOfNations wrote:
             | It is very normal for devices to have multiple IPv6
             | addresses. Pretty much every device will have at least two:
             | a link-local address and a public address. When
             | autoconfigured, some devices generate both a long-term and
             | a temporary public address.
        
             | pantalaimon wrote:
             | The internal address is optional, it's only useful if you
             | want to have a known address if your uplink is down so you
             | can do maintainance.
             | 
             | You only need two addresses:
             | 
             | - a global address
             | 
             | - a link-local address
        
               | nottorp wrote:
               | Not clear. How do i reach a device in my local network?
               | Via the optional internal address if my uplink is down
               | and via my link-local address if my uplink is up?
               | 
               | Is the link-local address any good if i'm on wifi but
               | want to ssh into a wired host in my home?
               | 
               | Are you getting my point yet?
               | 
               | Edit: actually I won't wait. The point is it's needlessly
               | overcomplicated. It was done by a commitee that didn't
               | even consider people could try to set up their home
               | network. It's good enough for the enterprise (except
               | cloud sellers it seems) and the plebs should just buy a
               | router.
               | 
               | They also didn't consider someone would try to use the
               | command line, since those addresses are not typable.
        
               | yesco wrote:
               | > Is the link-local address any good if i'm on wifi but
               | want to ssh into a wired host in my home?
               | 
               | Lets breath and think about this for a second, you want
               | to know how to reach a device on your local network, your
               | host has a "link-local" address. Could there be a
               | connection here?
               | 
               | The answer is yes because it's in the name, it's
               | literally in the name, why are you confused? What is over
               | complicated about this?
               | 
               | Back when I was in college I did IPv6 compliance testing
               | as a part time job. Me and random other freshman computer
               | science + IT students were able to pick this up after a
               | day or two of training with next to zero network
               | experience. I really can't help but see your complaints
               | about complexity as nothing but the whining of a child.
               | (we also exclusively used the commandline)
        
               | pantalaimon wrote:
               | I think you are a bit confused.
               | 
               | A global address is an address that is routable over the
               | internet. You can reach it from anywhere as long as your
               | firewall permits so.
               | 
               | A link-local address is never routed. It is only valid on
               | a single network segment. You can use it if your uplink
               | is down and you don't have multiple networks at home. It
               | is usually derived from the MAC address of your NIC.
               | 
               | There are some special link-local multicast groups,
               | ff02::1 is the 'all nodes' address. If you send something
               | there it will be received by all hosts on the link.
               | 
               | ff02::2 is 'all routers' - this will be received by all
               | routers on the link. There are more [0].
               | 
               | If you have multiple internal networks and want to reach
               | hosts without an uplink, you can use the unique local
               | address range fc00::/7
               | 
               | This functions just like 10.0.0.0/8 on IPv4 and is only
               | routed within your site.
               | 
               | [0] https://www.iana.org/assignments/ipv6-multicast-
               | addresses/ip...
        
             | ipython wrote:
             | Actually there can be an arbitrary number of addresses per
             | device, thanks to the privacy extensions. Since your
             | "device id" is a simple derivation of your MAC address,
             | technically you could be tracked across ipv6 networks
             | through that.
             | 
             | Therefore most modern oses will create a time limited
             | random address (within the prefix) to use. When the
             | connections using that address have died, the address is
             | retired. New addresses are generated on a periodic basis.
             | So if you have long lived connections you could have
             | several active privacy addresses at the same time.
        
           | cj wrote:
           | I have the technical ability to set up a well structured VPC
           | in AWS with private/public subnets, but I wouldn't know where
           | to start if asked to set up an ipv6-only network.
           | 
           | Is the general model of public/private subnet still valid? Or
           | are you saying in a ipv6-only world, there's no need for
           | separate subnets?
           | 
           | There's something about a server not being assigned an IP
           | address at all that makes me sleep easy at night (in ipv4
           | world, you know that server is truly unreachable via public
           | internet)
        
             | rootusrootus wrote:
             | > Is the general model of public/private subnet still
             | valid?
             | 
             | You're getting replies that are tiptoeing around the truth,
             | saying that the answer to this is basically 'yes' when it
             | sure looks like the answer is firmly 'no.' My home IPv4
             | network isn't routable, it is a private network. If my IPv6
             | address is globally unique and addressable by someone
             | across the world, my network is not private in the way that
             | most people have come to understand the term. I'm just part
             | of the public network but with a firewall to stop unwanted
             | packets from reaching my local nodes.
        
               | yesco wrote:
               | > My home IPv4 network isn't routable, it is a private
               | network.
               | 
               | An IPv6 network with a firewall configured to disallow
               | incoming traffic isn't routable, it is a private network
               | 
               | > If my IPv6 address is globally unique and addressable
               | by someone across the world, my network is not private in
               | the way that most people have come to understand the
               | term.
               | 
               | In what way? All NAT does is funnel traffic over one
               | address (or more), that address is still exposed to the
               | internet and it's your firewall that prevents that
               | incoming traffic. If your firewall is compromised, then
               | NAT isn't protecting you from anything, your network will
               | absolutely be routable despite what you are suggesting.
               | The assumptions you are making are part of the reason why
               | NAT can be dangerous.
               | 
               | > I'm just part of the public network but with a firewall
               | to stop unwanted packets from reaching my local nodes.
               | 
               | This is an oxymoron, you are either a part of the public
               | network or you are not. The only thing that has changed
               | is the semantics.
        
             | yesco wrote:
             | I generally see IPv6 being a better reflection of reality
             | vs the illusion presented by IPv4/NAT. To put it another
             | way, even if your server has no public IP address, if
             | someone punches through your firewall it's not like that
             | matters anymore right? If they have the keys to the kingdom
             | they can change your network to be however they like.
             | 
             | If your network is a house, and your firewall is the front
             | door, then all NAT does is force you to have a weird
             | fractal room layout where rooms are inside rooms, inside
             | rooms. But if a dude breaks in through your front door, it
             | doesn't matter how many rooms you have, he will find what
             | he wants.
             | 
             | IPv6 lets you have as much rooms as your want and lets you
             | optionally send mail to specific ones. If someone breaks in
             | they still have access to everything, but instead of having
             | to navigate a fractal house, they have to navigate a house
             | with a nicer layout and a trillion doors.
             | 
             | The metaphor is falling a part a bit here but my point is
             | that if your server has some form of physical network
             | connection that eventually leads to the internet, it's
             | address scheme isn't going to help you much, even if it
             | makes you sleep better.
        
             | ActorNightly wrote:
             | Its pretty much the same.
             | 
             | The reason why NAT with ipv4 works is because routers by
             | default do not forward any incoming traffic from outside to
             | inside host unless there is an entry in the lookup table
             | based on ports or based on port forwarding rules. The
             | important thing to realize is that the local ip addresses
             | (192.x, 10.x, e.t.c) don't actually matter - they can be
             | replaced with any schema as far as router is concerned, and
             | made public. And this is because the core routing logic of
             | the entry table based on port doesn't change.
             | 
             | Ipv6 implementation doesn't really differ in this. With
             | IPV6 routers can deny incoming traffic to the particular
             | machine without a previous outgoing request connection,
             | just like in the IPV4 NAT implementation. Receiving end
             | knowing the full ip address of the machine (and even then,
             | with privacy extensions, that ip address will no longer be
             | valid in a day) doesn't really do anything against you
             | security wise.
             | 
             | However, unlike IPV4, if you actually want to set up
             | connectivity across networks and in fact enable routers to
             | forward traffic based on the ip address, you don't have to
             | deal with NAT translation, udp hole punching, e.t.c.
             | 
             | And furthermore, forcing harder endpoint security is a good
             | thing. Routers are notoriously easy to exploit in a lot of
             | cases, and once an attacker is on a router, NAT is
             | worthless. Likewise for IoT devices that can be exploited
             | through http based attacks against central servers also
             | give you the same access.
        
             | Arnavion wrote:
             | >Is the general model of public/private subnet still valid?
             | Or are you saying in a ipv6-only world, there's no need for
             | separate subnets?
             | 
             | Define "public/private". Your server has an IPv6 address
             | that is globally identifiable. Your gateway may not
             | necessarily route traffic to it.
             | 
             | >(in ipv4 world, you know that server is truly unreachable
             | via public internet)
             | 
             | You don't know that, because a port forward rule on the
             | gateway would route traffic to it after doing NAT. And if
             | you made the effort to know that your gateway doesn't have
             | such a rule, then you can equally make the effort to know
             | that your gateway doesn't have a rule to forward traffic to
             | the server's subnet.
        
         | unethical_ban wrote:
         | Bookmarking for future. I want to fill this out but don't have
         | the info in front of me at the moment.
        
         | argulane wrote:
         | Everything should get its IPv6 configuration via SLAAC. DHCPv6
         | is only useful when you plan to provide prefix delegation for
         | extra routers or network boot information.
        
           | pantalaimon wrote:
           | You can even do prefix delegation with SLAAC, although not
           | really in a standard way
           | 
           | https://doc.riot-
           | os.org/group__net__gnrc__ipv6__auto__subnet...
        
           | tjoff wrote:
           | So how do you do DNS then?
           | 
           | Not sure if this is a good source but it had some history to
           | recap, and it doesn't look pretty... https://www.reddit.com/r
           | /networking/comments/ajb2ec/comment/...
           | 
           |  _[...] To be honest because of this hot mess if you want to
           | reliably support any possible client you 'll need to do both
           | DHCPv6 and RDNSS for DNS information. [...]_
        
             | labcomputer wrote:
             | That source is, at best, dated.
             | 
             | Sending DNS info is one of the options in SLAAC (just like
             | how it is an option for DHCPv4).
             | 
             | You just configure your router to advertise DNS servers via
             | SLAAC Router Advertisements (RAs) the same way you would
             | via DHCP.
             | 
             | One of the benefits is that any configuration changes
             | propagate almost immediately--you don't have to wait for
             | DHCP clients to renew their lease to get new DNS servers.
             | 
             | Also, you can (if you want) have the DNS server advertise
             | itself using the same mechanism.
             | 
             | The only common clients that can't use SLAAC-based DNS
             | configuration are older (unsupported) versions of windows.
             | Even then, setting up DHCPv6 (in unmanaged mode) to send
             | DNS servers is easy.
        
             | porbelm wrote:
             | The SLAAC should not change after the host has generated it
             | during installation / first connection, as long as you
             | don't reinstall the OS etc.
             | 
             | It's basically no problem.
             | 
             | Even better: I can set my own ::/64 so personal servers at
             | home can be ::d3ad:b33f and accessible from outside without
             | NAT. It's beautiful. Firewall configuration is not hard
             | either these days is it?
        
               | tjoff wrote:
               | So I have to manually configure every device to be able
               | to use internet?
               | 
               | Every friends phone that wants to connect to my wifi
               | needs manual setup?
               | 
               | That is a problem. To which the solution is IPv4?
        
               | yesco wrote:
               | Why do you think this? What led you to assuming these
               | things?
               | 
               | You would only need to configure any of this if you want
               | to allow external connections, which isn't much different
               | than setting up port forwarding with IPv4 + NAT, except
               | with IPv6 it's less complicated.
        
               | tjoff wrote:
               | Literally the post I answered.
               | 
               | Fact: SLAAC does not do DNS. So, my question then is: how
               | do you do DNS?
               | 
               | Answer: _" The SLAAC should not change after the host has
               | generated it during installation / first connection, as
               | long as you don't reinstall the OS etc."_
               | 
               | Since SLAAC does not do DNS that answer implies that
               | you'd enter it during connection/installation to complete
               | the config.
        
               | jeroenhd wrote:
               | SLAAC installations can use RDNSS to configure DNS.
               | 
               | Windows, according to Wikipedia, doesn't support it, but
               | if you want to please Microsoft there's stateless DHCPv6
               | (which does not maintain leases, configure addresses, or
               | do anything else that SLAAC doesn't do already; it can be
               | simple piece of software in comparison).
               | 
               | On the other hand, Android and ChromeOS don't support
               | DHCPv6 for DNS server provisioning because of Google's
               | opinion about all matters related to DHCPv6. A pain, but
               | not impossible to overcome either.
               | 
               | As for unchanging addresses, SLAAC is bound to the device
               | MAC address so a reinstall should give you the same IP.
               | However, you are/should be running privacy extensions,
               | which means your outgoing IP will rotate to prevent
               | tracking (as your IP is based on your MAC address and
               | using that would make tracking way too easy). You'll
               | still have the same primary IP, though, unless you add a
               | second device to the network with the same MAC address.
        
               | tjohns wrote:
               | Windows supports SLAAC+RDNSS, as long as you're running
               | Windows 10 or newer.
        
               | tjohns wrote:
               | What? No. You connect a device, and SLAAC (and optionally
               | DHCPv6, on enterprise networks) configures everything. It
               | just works.
               | 
               | SLAAC is more than capable of sending DNS settings to
               | devices. There's no manual configuration involved.
        
               | tjoff wrote:
               | My post said to use DHCPv6 and RDNSS. Follow up claimed
               | to use SLAAC instead.
               | 
               | SLAAC does not do DNS. Clear as day?
        
               | tjohns wrote:
               | SLAAC does DNS, with the RDNSS extension enabled. (RDNSS
               | is a feature that was added to SLAAC.)
               | 
               | Some older devices [1] do not support RDNSS. I haven't
               | run into them, but if you're at all worried about it, you
               | can run DHCPv6 in parallel just to hand out DNS settings.
               | 
               | Personally, I just use SLAAC (with RDNSS) and it just
               | works.
               | 
               | [1]: https://en.wikipedia.org/wiki/Comparison_of_IPv6_sup
               | port_in_...
        
               | ipython wrote:
               | I run dual stack at home and every device I have
               | connected to my home network runs ipv6 with no manual
               | configuration whatsoever. It's easier than ipv4 when you
               | consider providing inbound access to resources (no nat
               | configuration)
        
             | staringback wrote:
             | IPv6 router advertisement.
        
             | tjohns wrote:
             | SLAAC can configure DNS automatically (via RDNSS).
             | 
             | Or you can run DHCPv6 just to hand out DNS settings (or
             | anything else you want more control over), even if it's not
             | handling addressing. But this isn't necessary for small
             | deployments.
             | 
             | Personally, I've never had any problems with pure SLAAC (no
             | DHCPv6) on my home network.
        
           | stevefan1999 wrote:
           | just a funny joke: what about using IBGP/OSPF for prefix
           | delegation?
        
             | justin_oaks wrote:
             | How does that work you have more than one ISP giving you an
             | IPv6 prefix?
        
       | lee101 wrote:
       | I just like to call out Starlink for not supporting ipv6, massive
       | headache as calls to various ipv4 only sites fail in python then
       | you need to set a timeout in your request to trick python into
       | falling back to ipv4, also no public adresses on Starlink made
       | self hosting https://text-generator.io a pain but CloudFlared
       | tunnels helped
        
         | tinglymintyfrsh wrote:
         | Aside about AI text generation: Rule 34 will be tested when it
         | comes to generating adulting text content.
        
       | badrabbit wrote:
       | My take is that they should have used alphanumeric addressing.
       | You could have addresses like company:office:laptop and it
       | shouldn't have reinvented arp and dhcp or added more complex
       | routing like anycast or link local. It tried to solve too many
       | problems at once.
        
         | notdonspaulding wrote:
         | How would alphanumeric addressing help anything?
         | 
         | You currently have an address hierarchy like <AS
         | Number>:<Network Allocation>:<Subnet>:<Host>. That hierarchy is
         | conveniently conveyed in a single 128 bit number. With an
         | alphanumeric address, 128 bits of ASCII would get you
         | `company:office:l` and your net/subnet/host would require more
         | CPU horsepower to compute.
        
         | Dagger2 wrote:
         | You're thinking of DNS, which... we already have.
         | 
         | v6 actually changed very little from v4. It more or less works
         | in exactly the same way v4 does.
        
       | ArchOversight wrote:
       | Yes, I use IPv6 in production, alongside IPv4 (dual-stack). I've
       | got an IPv6 only EKS cluster that has IPv4 on the local instance
       | that NAT's any IPv4 outgoing connections, but the entire cluster
       | and all communications inside the cluster/between pods is IPv6
       | only.
       | 
       | IPv6 stand-alone without IPv4 dual stack is not yet an option,
       | but it is getting closer. If you can mirror content and deploy
       | from your mirrors it is entirely possible to do everything over
       | IPv6 alone.
       | 
       | About 30% of my production traffic is IPv6, referring to outside
       | traffic coming in to the systems. Internally almost 90% of the
       | traffic is IPv6 due to the k8s cluster being IPv6 only, and
       | preferring that over IPv4.
       | 
       | Interestingly enough at home on my home connection about 60% of
       | my traffic is IPv6, which has been increasing steadily over the
       | years as other companies have started bringing on-line IPv6 for
       | their services.
        
       | Aissen wrote:
       | One interesting thing is the asymmetry making it slower for all
       | those backend services to move, as opposed to, say, a brand new
       | ISP.
       | 
       | Cloud/hosting services only need one IPv4 per machine, making
       | them relatively cheap, and easy to include in pricing. ISPs need
       | one IPv4 per customer, or resort to CGNAT or IPv4-sharing. This
       | often means that customers might have better IPv6 than IPv4
       | performance. All of this does not apply to oldest ISPs that all
       | have a war-chest of IPv4 they got for cheap (free).
       | 
       | Where I'm getting at is that the usecase you're testing is
       | basically worst-case scenario. Fun that Hetzner does not even
       | have AAAA records for their API. Do they have at least RFC1918
       | (private) IPv4 addresses ?
        
       | alexfromapex wrote:
       | I think it's the format of the numbers that's not user-friendly
       | enough. They can be too long to remember and my first thought is
       | that there should be a clever algorithm to use "catchy names" or
       | words and then map them to the numeric values. Could even down-
       | sample the names/words that need remembering and then up-sample
       | them to the full numeric range behind the scenes to help add a
       | larger range of values.
        
       | tinglymintyfrsh wrote:
       | There are large swaths at work that are IPv6 only. There is a
       | proxy to work with things like Github that don't do it.
       | 
       | Ideally, every OS and device should be able to do IPv[46] only
       | and dual-stack.
       | 
       | IoT stuff has the most problems where they're 2.4 GHz and IPv4
       | only.
        
       | anticristi wrote:
       | 15 years ago I connected 1000s of computers natively to the IPv6
       | Internet. Today, I don't have IPv6 at home.
       | 
       | DJB was right, I'm afraid.
        
       | mcguire wrote:
       | If the question is, "Why isn't IPv6 the most prominent protocol
       | and v4 a legacy thing?" the answer is NAT and RFC1918 addresses.
       | And NATs within NATs within NATs. The only "real" v4 address you
       | need is for your publicly facing servers.
       | 
       | There has been no incentive to go to v6.
        
       | trey-jones wrote:
       | The furthest I ever got was creating firewall rules for ipv6 that
       | mostly corresponded to our ipv4 rules. These were never used, but
       | they were tested and ready. This was around "ipv6 day" (2014?
       | 2015?) I've thought about it on and off since then and wondered
       | whether I should be doing more with ipv6, but haven't actually
       | taken any action in that direction.
       | 
       | I wonder if there's a _relatively_ simple solution to at least
       | most of the OPs list, all having to do with outgoing ipv6
       | requests, which would be proxying such (or all) requests through
       | another computer on the network that has both ipv4 and ipv6
       | interfaces. Maybe that is an oversimplification.
       | 
       | Anyway, ipv4 definitely has a problem, and something is going to
       | have to be done eventually.
       | 
       | Edit regarding World IPv6 day. I must be thinking of June 6,
       | 2012: "This time, it's for real."
        
         | noipv6 wrote:
         | > Edit regarding World IPv6 day. I must be thinking of June 6,
         | 2012: "This time, it's for real."
         | 
         | world ipv6 day (24 hours) was in 2011.
         | 
         | world ipv6 launch (turn it on & leave it on) was in 2012.
         | 
         | (ppl mix the two up all the time, understandably!)
        
         | jeroenhd wrote:
         | > I wonder if there's a relatively simple solution to at least
         | most of the OPs list, all having to do with outgoing ipv6
         | requests, which would be proxying such (or all) requests
         | through another computer on the network that has both ipv4 and
         | ipv6 interfaces. Maybe that is an oversimplification.
         | 
         | If you have an IPv4+IPv6 capable server around, you can set it
         | up yourself if your ISP hasn't made a proxy available. There
         | are various NAT64 implementations you can use; running them and
         | setting up a DNS64 server is all you need to make such a
         | feature available. You'd probably also want to add a
         | firewall/whitelist to prevent other abusing your NAT64 gateway,
         | though.
        
       | pm2222 wrote:
        
       | geraldcombs wrote:
       | Is there an "awesome"-style list of things that are slowing
       | server-side IPv6 adoption? If not, these would be a good start.
        
       | delduca wrote:
       | I had to disable IPv6 on my macOS in order to download packages
       | from GitHub that brew uses, it took me days to figure out the
       | problem.
        
       | ps0ps wrote:
       | Totally viable.. Been IPv6-only since Fall 2014
       | https://www.internetsociety.org/blog/2014/06/facebook-moving...
        
       | noipv6 wrote:
        
       | KomoD wrote:
       | > Our Hosting provider, Hetzner, has recently started charging
       | for public IPv4 addresses
       | 
       | Well actually, they were charging for IPv4 addresses for a while,
       | but just changed pricing... to outrageous pricing. The setup fees
       | are actually insane!
       | 
       | And yeah IPv6-only is quite a terrible experience, I tried out a
       | few days ago. I suggest just using nat64.net if you want to
       | access IPv4 sites over IPv6.
       | 
       | One quite funny thing, I recently asked my ISP if they were ever
       | going to add IPv6, they told me no, there's "not enough
       | demand"... well there's "not enough demand" because there's
       | barely any IPv6 websites, and then websites refuse to add support
       | for IPv6 because... you guessed it, "not enough demand".
        
         | Tempest1981 wrote:
         | Pricing, fyi:
         | https://docs.hetzner.com/general/others/ipv4-pricing/
         | 
         | Around EUR19.00 setup per IP.
        
           | Sesse__ wrote:
           | That's not insane, that's pretty cheap. If you buy IPv4
           | addresses in bulk (e.g. an entire /18 or so), they're ~$40 a
           | piece these days.
           | 
           | When you buy cloud services from AWS or GCE, you're still
           | paying for those IPv4 addresses, it's just baked into the
           | price. Hetzner makes paying for it optional, which makes it
           | so much more visible.
        
             | counttheforks wrote:
             | It is an insane price for _renting_ an IP address. It 's
             | not like you get to keep the IP address when you move
             | elsewhere.
        
             | KomoD wrote:
             | This isn't buying, this is renting. You are paying that
             | setup fee + the monthly fee.
             | 
             | As a comparison, I pay ~$1.60/ip/mo (no setup fee) for my
             | IPs.
        
           | terom wrote:
           | My guess would be that you need to let used IPv4 addresses
           | age out for a while before you can reassign them to a new
           | customer, and they need to reduce churn - and avoid people
           | intentionally burning IPv4 addresses by rotating through new,
           | clean addresses.
        
         | counttheforks wrote:
         | > The rental costs for the current hosting is quite affordable
         | for me. If that becomes insufficient I will look for
         | partnerships with transit providers who are able to make a
         | little profit from carrying parts of the traffic.
         | 
         | Well, that's ominous. Basically a promise that they will sell
         | your data.
        
       | sph wrote:
       | Yearly reminder that Hacker News still is IPv4 only.
        
       | eestrada wrote:
       | > Our Hosting provider, Hetzner, has recently started charging
       | for public IPv4 addresses - as they should! Those numbers started
       | getting expensive. This prompted me to try and set up a new
       | server cluster using IPv6 exclusively...
       | 
       | I think what OP went thru is what will make the transition
       | happen. Market forces are ultimately going to be the thing that
       | drives wider adoption: IPv4 addresses getting so expensive that
       | it drives people to try IPv6, and when that fails they complain
       | in posts like this and directly to their service providers. The
       | fact that OP names names of services failing to offer IPv6 is a
       | good thing. Ideally it will start creating pressure on those
       | services/corporations to fully support IPv6. If complaining
       | doesn't work to motivate them, users moving away from their
       | services to providers who do offer IPv6 support will motivate
       | them.
        
       ___________________________________________________________________
       (page generated 2022-12-07 23:01 UTC)