[HN Gopher] IP Addressing in 2021
       ___________________________________________________________________
        
       IP Addressing in 2021
        
       Author : janeric
       Score  : 102 points
       Date   : 2022-01-21 12:57 UTC (10 hours ago)
        
 (HTM) web link (blog.apnic.net)
 (TXT) w3m dump (blog.apnic.net)
        
       | rwmj wrote:
       | Has anyone here deployed an IPv6- _only_ web server (say as a
       | personal or other non-critical website), and how did that go? Is
       | it practical yet?
        
         | DarylZero wrote:
         | All of the laptops/computers in my house have IPv6-only web
         | servers with LetsEncrypt certificates. (These computers all
         | share a single IPv4 address.)
         | 
         | To get IPv6 on all computers I just installed radvd on the
         | router. On the router I also set up a VPN to give the IPv6
         | addresses over IPv4 even when they're not local.
         | 
         | It's great.
        
         | sekh60 wrote:
         | I have a small ceph cluster over ipv6 and also a small
         | OpenStack cluster with the daemons and web interface all
         | running over V6 only. My network is dual stack since not all
         | external networks are V6 compliant, and since I cannot seem to
         | get cephadm's built in NFS service working over V6, so some of
         | my local fileshares need v4.
        
         | miyuru wrote:
         | Yes, I run a site with 4 IPv6 only VPS servers with around 9M
         | requests per month with the help of cloudflare.
         | 
         | In the past, setting up the server was hard(npm, composer,
         | docker) but it has become less of a problem now.
         | 
         | GitHub is the major pain point even now. Even though I use
         | bitbucket for scm which supports IPv6, surprising number of
         | developer tools is centralized on GitHub.
        
         | api wrote:
         | I've used IPv6-only VPSes as jump boxes in the past.
        
         | bin_bash wrote:
         | My ISP (frontier) doesn't even give me IPv6 yet so if someone
         | did this I wouldn't be able to access it.
        
           | Bluecobra wrote:
           | You might be able to access it if you have an Apple device
           | and Private Relay enabled. I only have IPv4 at home and was
           | surprised to see an IPv6 address when I typed in "what is my
           | ip" into Google. For the most part, Private Relay works
           | pretty good.
           | 
           | Maybe the solution for more IPv6 adoption is for tech giants
           | like Apple, Google, Microsoft to make proxies like Private
           | Relay ubiquitous on every device/browser.
        
             | bin_bash wrote:
             | Yeah it's actually come up twice that I needed IPv6 and for
             | that I just logged into my work VPN
        
           | kxrm wrote:
           | You should definitely setup a 6to4 tunnel. HE gives them
           | away.
           | 
           | https://www.tunnelbroker.net/
        
             | jandrese wrote:
             | I set one up over a decade ago because Verizon said that
             | they would need 6 months to deploy IPv6 on FiOS. I'm still
             | using it.
             | 
             | Unfortunately in the meantime spammers have discovered HE
             | tunnels and now I get a lot more CAPCHA's than I used to. I
             | still check my FiOS link every month to see if Verizon has
             | turned it on yet.
        
         | pantalaimon wrote:
         | Do IPv6-only sensor networks count?
        
         | Klathmon wrote:
         | I had my personal home assistant instance exposed IPv6-only for
         | a while a few years ago.
         | 
         | It worked perfect for that in almost every situation since my
         | cell carrier supported v6 so any time I'm not home I could
         | still access it.
        
         | p_l wrote:
         | BTW:
         | 
         | Original implementation of DirectAccess (Always-On, transparent
         | VPN) in Windows Vista required working IPv6 connection, this
         | was extended with HTTPS-over-v4 backup tunnel support later on
         | when MS found out how hard it was to get consumer v6 in 2007.
         | Inside of DirectAccess, connectivity is pure v6 still.
         | 
         | In fact, since NT6, Windows is IPv6-first system in many
         | aspects, and Microsoft made news last year when they complained
         | that they couldn't disable v4 on _guest wifi_ at many offices
         | due to non-Microsoft visiting workers having issues connecting
         | to their VPNs due to software that didn 't work with
         | NAT64/DNS64.
        
         | ewired wrote:
         | My first home server was IPv6-only, straight off of my ADSL
         | router with a public static IPv6 address and domain dedicated
         | to entirely to a Raspberry Pi. It worked perfectly on mobile
         | and at home. What a pain in the ass when I discovered my
         | university didn't support IPv6 in any capacity. Their ASN has
         | v6 blocks but no v6 routes on campus.
        
         | xPaw wrote:
         | I have experimented with IPv6 only, but a lot of stuff still
         | doesn't support it. For example Github and Discord webhooks
         | fail to send.
        
         | cytzol wrote:
         | I set up a non-public-facing IPv6-only web server last night,
         | so the issues are fresh in my mind! I'm fortunate enough to
         | have an IPv6-capable home connection, and the hosting provider
         | I use (Scaleway) charges extra for assigning IPv4 addresses to
         | machines, so I thought I'd see how easy it would be to save a
         | bit of money and make this machine IPv6-only. I've IP-filtered
         | the host to only my home and my other servers, so having IPv4
         | support _should_ be a waste.
         | 
         | The machine is now running fine, but I had a few roadblocks
         | setting it up:
         | 
         | * My provisioning scripts download a release of 'dry'[0] from
         | GitHub, which does not support IPv6. I ended up assigning my
         | new machine a temporary IPv4 address and removing it later.
         | 
         | * The scripts also import a key from 'keyserver.ubuntu.com'[1],
         | which, again, does not support IPv6. Attempting to connect just
         | timed out, and if I hadn't just solved the _other_ issue, I
         | would have assumed the host was down.
         | 
         | * There seems to be a bug in Scaleway's cloud firewall (the
         | things it calls Security Groups), where you cannot allow
         | inbound ICMPv6, only standard ICMP (for IPv4). This meant my
         | pings never responded and I thought the machine wasn't up when
         | it _was_ up.
         | 
         | Basically, what I want you to take away from this post is that
         | if you disable IPv6, it's still the case that during
         | maintenance, things are going to break, often mysteriously and
         | with bad error messages, but outside of maintenance, things
         | will likely run smoothly. My machine runs Sentry, and after the
         | problems I had setting it up, I didn't dare run the Sentry
         | './install.sh' script with IPv4 disabled as I didn't trust it
         | to handle that case correctly -- and even if the script
         | reported no errors, I wouldn't have trusted there to actually
         | _be_ no errors. Since then, though, it 's been running fine, so
         | having an IPv6-only server is certainly possible, even if you
         | have to give in and assign it an IPv4 address at the start,
         | then take it away again later.
         | 
         | [0]: https://github.com/moncho/dry [1]:
         | https://keyserver.ubuntu.com/
        
       | zamadatix wrote:
       | I'm not sure I agree with Geoff's concern on fragmentation of the
       | IPv4 internet due to growth and lack of v6 migration. I
       | absolutely agree the increased cost of maintaining ever more
       | complex and larger scaled NATs is going to continue to drive IPv6
       | migration but that these are possible is exactly why
       | fragmentation won't happen in my mind.
       | 
       | The cost of fragmentation (due to growth, not other factors like
       | national politics) is far greater than the cost of running even
       | multiple levels of NAT (e.g. CG-NAT) and, apart from already
       | being done in many places today, this scales to nearly the same
       | level as IPv6. Yes, IPv6 has 128 bit addresses but over half of
       | this address space will be "wasted" for ease of use like /64s
       | and/or ease of allocation like allocating enormous blocks that
       | will be sparsely filled with /64s for decades to come. Meanwhile
       | GC-NAT allows nearly 100% utilization of any public IPs via
       | dynamic assignment. Suddenly adding nearly 32 bits (there will be
       | inefficiencies so it won't be the theoretical 32) of address pool
       | on top of the nearly 32 bits address pool isn't all that far from
       | the "128" bits of IPv6. It is however god awful complicated,
       | slower/more latent due to needing to go to NAT points, and needs
       | more centralized care and feeding to keep running, but not really
       | at risk of being to limiting to drive a fragmented internet in
       | anyone's lifetime due to "running out of NAT" or such.
       | 
       | Hopefully however these pressures from the burden of NATs and the
       | ability to do more than just client+server model on TCP/UDP like
       | the article points out and continues driving IPv6 to the point
       | NAT64 becomes cheaper/easier to run and use than dual stack with
       | v4 NAT.
       | 
       | Obligatory off topic plug (sorry dang) about this tech hacker
       | site still being v4 only.
        
         | immibis wrote:
         | Note although half the bits in IPv6 are wasted under current
         | schemes, almost 7/8 of the IPv6 space is unused, precisely so
         | that if we screw up the public allocation we have many more
         | chances to start over.
         | 
         | And there is no fundamental technical limitation on subnets
         | smaller than /64, either. Should 45 bits not be enough (and it
         | won't be, not forever!) we could start using DHCPv6 on smaller
         | subnets, instead of using SLAAC.
        
           | jandrese wrote:
           | There is a lot of assumptions that are broken if you try to
           | allocate something smaller than /64. It would be like trying
           | to re-assign the multicast address space for unicast.
           | 
           | But running out of space on IPv6 is seriously not a concern.
           | Even a "paltry" 64 bits of address space is an absurdly large
           | number of addresses. Humans need to have colonized the entire
           | galaxy before it becomes an issue.
        
             | immibis wrote:
             | I believe the current allocation plan allows for 2^45
             | "customers" getting a /48 each. While we don't have 2^45
             | _humans_ get, it 's not too hard to imagine having more
             | than one "customer" per human especially due to
             | corporations and multi-homing, and there will be unused
             | space due to hierarchical allocations, and I'd say that
             | with 128 bits available, probably more than 10 of them
             | should be devoted to future-proofing.
             | 
             | If each customer were to get a /64 or a /60 or perhaps a
             | /56 by default, that would leave plenty of room for
             | inefficient hierarchical allocation and future-proofing.
             | But that doesn't leave many bits for subnetting.
             | 
             | To my knowledge, the only thing that breaks in subnets
             | smaller than /64 is automatic address assignment, i.e.
             | SLAAC and privacy addresses, which are in no way required,
             | merely convenient.
        
               | Arnavion wrote:
               | Nothing breaks _irrevocably_ in subnets smaller than
               | /64, including SLAAC and privacy addresses. You just need
               | NDP proxies between them.
        
               | jandrese wrote:
               | There are plenty of second order effects though. Like
               | IPv6 blacklists operating at the /64 level or higher.
               | Sharing a /64 is like being behind the same natted IPv4
               | address as a bad guy.
        
               | oarsinsync wrote:
               | > Like IPv6 blacklists operating at the /64 level or
               | higher
               | 
               | Several blocklists I'm aware of block at /48s, not at
               | /64s, on the basis that customer allocations (per the
               | spec) are supposed to be /48s.
               | 
               | Not enough people use IPv6 right now, so the level of
               | complaints from this is low->zero.
        
               | Arnavion wrote:
               | RFC6177 (2011) obsoleted the recommendation (which is all
               | it was to begin with, not a "supposed to") that end users
               | should get /48s.
        
               | Arnavion wrote:
               | Right, I wasn't saying that giving end-users something
               | smaller than a /64 should actually be done. Not only does
               | it require more effort but also it breaks higher-level
               | things as you said. I was just saying that there's no
               | technical breakage that would occur, especially not SLAAC
               | or privacy addresses.
        
             | oarsinsync wrote:
             | > There is a lot of assumptions that are broken if you try
             | to allocate something smaller than /64. It would be like
             | trying to re-assign the multicast address space for
             | unicast.
             | 
             | Can you go into some details as to what breaks? I ran a
             | dual-stack network with /112s for host subnets, and /124s
             | for ISLs (prefix lengths chosen to make life easier for the
             | network operators) and I wasn't aware of any problems.
             | 
             | Certainly, you can't use (formerly known as) class D
             | address space in IPv4 as the major IPv4 stacks will balk if
             | you do, and you're never gonna get into class E space
             | either for similar reasons, but ... to use a longer prefix
             | length than /64 in IPv6? I'm unaware of any implementations
             | that fall over, but it's been a few years since I paid any
             | real attention.
        
             | mortenlarsen wrote:
             | Yes, 64 bits is the same amount of space as an entire IPv4
             | Internet NAT'ed behind every IPv4 address on the current
             | Internet. Actually more if you take multicast and reserved
             | addresses into account.
        
       | hcurtiss wrote:
       | It seems to me like IPv6 is a good candidate for legislation.
        
         | p_l wrote:
         | Funnily enough, the first attempt at such legislation back when
         | there was much less commercial use of internet kinda failed due
         | to vendor pressure and allowances for continued use of IPv4
         | (this was specific to DoD/Government networks, and was supposed
         | to migrate to OSI and its up-to 20 bytes addresses)
        
           | jandrese wrote:
           | Most government sites just set up Cloudflare IPv6->IPv4
           | translation frontends to check the box.
        
         | jandrese wrote:
         | If I were a dictator I would just put a deadline on it. January
         | 1 2027: IPv4 forwarding is turned off on all core routers.
         | 
         | You can still use IPv4 internally if you have legacy devices,
         | but anything on the Internet has to use IPv6. You have about 5
         | years to get it done. There are lots of solutions for specific
         | use cases including stuff like ::ffff:1.2.3.4 and IPv4/IPv6 NAT
         | devices. Most of which won't be as necessary as people think
         | because IPv6 support is already widespread everywhere except
         | ISPs.
        
           | ISP_throwaway wrote:
           | Good thing you are a dictator.
           | 
           | No need to worry about silly things like the popularity of
           | such a move, the cost involved and the mountain of e-waste
           | produced.
        
         | pojntfx wrote:
         | China is already doing it:
         | https://www.theregister.com/2021/07/26/china_single_stack_ip...
        
           | ISP_throwaway wrote:
           | This is a great way of enhancing the Great Firewall of China:
           | simply cut off the rest of the world that is using IPv4.
        
           | DarylZero wrote:
           | It's just common sense regulation, we rarely get that in the
           | USA though.
        
           | imoverclocked wrote:
           | That is a good argument for why IPv6 is relevant everywhere
           | else for the luddites that refuse to implement it.
           | 
           | edit: luddite not meant in a derogatory sense. We need
           | luddites!
        
         | zokier wrote:
         | US government is pushing hard on IPv6, for example they have
         | this goal:
         | 
         | > At least 80% of IP-enabled assets on Federal networks are
         | operating in IPv6-only environments by the end of FY 2025
         | 
         | https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-0...
        
       | ISP_throwaway wrote:
       | The way I see it, IPv6 is somebody else's problem.
       | 
       | You can't make money with IPv6 and nobody wants it. From a
       | customer support perspective, IPv6 is just another problem nobody
       | needs.
       | 
       | We, and all the other ISPs in our market, have enough IPv4 for
       | the foreseeable future.
       | 
       | NAT works where you need to conserve addresses space and those
       | consumers that need a static IPv4 can get it, and what's better,
       | will pay for it.
       | 
       | IPv6 support on consumer devices is a dumpster fire. No way I am
       | touching that in production.
       | 
       | So, no, I have no plans to deploy IPv6 to customers. I will
       | reconsider when there's money in it, but preferably not before
       | various vendors have gotten their IPv6 shit together.
       | 
       | In other words, we the current ISPs in the market are good. Sucks
       | to be a new ISP though.
        
         | jiggawatts wrote:
         | > " We, and all the other ISPs in our market, have enough IPv4
         | for the foreseeable future."
         | 
         | Yours _might_ but mine ran out years ago.
         | 
         | No public cloud provider is able to provide a dedicated IPv4
         | address per endpoint, making cloud networking absurdly complex
         | unnecessarily.
         | 
         | Entire _continents_ are under provisioned and will never get
         | more allocation to meet future demand.
        
           | ISP_throwaway wrote:
           | > Yours might but mine ran out years ago.
           | 
           | Out of interest, why didn't you re-up when you still could?
           | 
           | You could still get some two years ago.
        
         | welterde wrote:
         | That's part of the problem: Old ISPs usually have plenty of IP
         | addresses hoarded and are less affected by the run-out.
         | 
         | It's more newly formed companies that are hit by this, since
         | they have none and have to buy them at ever increasing prices.
        
           | techsupporter wrote:
           | It is the classic example of FYGM. I'm old enough to remember
           | when being a "good netizen" would have meant that medium-
           | sized organizations would be pushing for the new standards
           | and practices that would allow newcomer organizations, maybe
           | even orgs that didn't yet exist, to join and participate on
           | the network.
           | 
           | Now we've wound up where IPv4 addresses are like houses:
           | everyone who already has one is quite content with the
           | situation (and even sees them as "investments" to be traded
           | and hoarded and leveraged) while newcomers are absolutely
           | hosed. And doing the right thing of expanding the pool of
           | availability, whether by allowing more housing to be built or
           | by migrating to IPv6, is met with cries of "there's no money
           | in it for me so I'm not interested."
           | 
           | And lest anyone thing this is petulant whining on the part of
           | a sysadmin from a new network, where I work has several
           | legacy IPv4 assignments and we own four or five low-digit
           | ASNs. We are set for life for IPv4, yet we've picked up our
           | IPv6 allocations from ARIN and have actively updated our
           | internal network such that all applications can work in a
           | v6-only environment and we've even donated some of our
           | address space to new organizations in our field (medicine)
           | who needed it to get started. _That_ is how the Internet is
           | supposed to work, through cooperation.
        
             | lanstin wrote:
             | Exactly right. good on you and your org.
        
         | usbqk wrote:
         | You can make money off ipv6: it allows for better tracking,
         | which is why Google, Facebook and friends are all ipv6 ready.
        
           | jandrese wrote:
           | I'm not sure that is true. It is true that you don't get
           | aliased by the NAT, but one of the features of IPv6 is that
           | you don't have to stick to a single address. Your system can
           | choose different source addresses for every connection if it
           | wants to. You will of course still be on the same /64, but
           | that is the same amount of tracking as IPv4/NAT provides.
        
         | nousermane wrote:
         | > consumers that need a static IPv4 can get it
         | 
         | Not necessarily. Some ISPs and majority of cell providers in
         | Europe only give you CGN IPv4. No IPv6, no static option.
        
           | pantalaimon wrote:
           | Huh at least in Germany DSLite is the norm, CGN IPv4 but
           | proper IPv6.
        
           | ISP_throwaway wrote:
           | I wasn't making a blanket statement about static IPv4
           | availability, rather it was an observation from our own
           | market.
           | 
           | That being said, most carriers or major ISPs aren't actually
           | that hard up for IPv4 space.
           | 
           | By no means will static IPv4s be available on all plans, but
           | merely changing AP or plan type will commonly result in the
           | ability to purchase a static IPv4.
           | 
           | It's mostly about lubricating with money to find a solution
           | rather than an all out lack of IPv4.
        
         | kstrauser wrote:
         | > NAT works
         | 
         | Stop right there.
        
         | hossbeast wrote:
         | As an ISP customer, you're the last one I would choose. I
         | highly value ipv6 connectivity in my choice of ISP. I think I'm
         | not alone.
        
           | oarsinsync wrote:
           | > As an ISP customer, you're the last one I would choose. I
           | highly value ipv6 connectivity in my choice of ISP. I think
           | I'm not alone.
           | 
           | When considering broadband connectivity, the major
           | considerations for the vast majority of consumers, when
           | signing their initial agreement, in order: price, speed,
           | reliability.
           | 
           | Heck, I run BGP from my home, and even I didn't consider
           | IPv6. But then I also have my own /22 of IPv4 (and a /32 of
           | IPv6), so that's probably why.
        
           | ISP_throwaway wrote:
           | That's fine, each to their own. You might not be alone, but
           | you should take into account that you are an atypical
           | customer.
           | 
           | Different customers value different things. In the list of
           | things people value in their broadband, IPv6 doesn't even
           | register for for the majority. There are markets where you
           | cannot even give away IPv6 connectivity.
           | 
           | Of those showing an interest in IPv6, many just want a static
           | IP. If you give them one then you have solved their problems
           | and are never heard from again.
           | 
           | If you really, _really_ want IPv6 then you _can_ usually get
           | it in most markets. You might have to upgrade to business
           | service or switch to an operator providing service over
           | legacy copper facilities. That is, however, a bridge too far
           | for almost everybody.
           | 
           | As an aside, you don't indicate that you would pay a premium
           | for IPv6 service. That's not very enticing from a business
           | perspective. If there was real demand for IPv6 or it could be
           | provided for a premium that would change.
           | 
           | It's a classical chicken and egg situation. No services
           | require IPv6, so there is no demand for IPv6 and thus no IPv6
           | offerings either.
           | 
           | I'd be interested to hear why you highly value IPv6
           | connectivity, especially if you had a static IPv4 allocation.
        
             | throw_nbvc1234 wrote:
             | > It's a classical chicken and egg situation. No services
             | require IPv6, so there is no demand for IPv6 and thus no
             | IPv6 offerings either.
             | 
             | AKA the ipv6 "blockchain" situation lol
        
         | yjftsjthsd-h wrote:
         | > IPv6 support on consumer devices is a dumpster fire. No way I
         | am touching that in production.
         | 
         | Is it still? I know this _was_ true for a while, but things
         | seem to have been ironed out. I only occasionally have IPv6 (my
         | ISP is doing something _weird_ ), but when I do it all seems to
         | work fine.
        
           | jandrese wrote:
           | Consumer device support is not a major problem, it is ISPs
           | that are the major roadblock. Corporate oriented devices are
           | also a slow to adopt however, which is one reason ISPs have
           | not made the switch.
        
             | labcomputer wrote:
             | Can you name some of these devices?
        
               | yjftsjthsd-h wrote:
               | Not them, but probably things like deep packet inspection
               | and ancient firewalls (that probably should be replaced
               | but, y'know, _enterprise_ )
        
               | jandrese wrote:
               | I know Fortigate SSL Inspection was/is broken on IPv6,
               | which killed IPv6 for some corporate users.
        
           | labcomputer wrote:
           | No. You are correct.
           | 
           | Good IPv6 host support has been a thing in almost all
           | consumer OSes for over 10 years now. All currently supported
           | versions of Windows, MacOS, Android[1][2] and iOS support
           | IPv6 natively.
           | 
           | And, as I keep reminding HN, Windows freaking _XP_ supported
           | IPv6 (albeit not as a transport for DNS queries).
           | 
           | The problem is simply that some people don't want to spend a
           | couple weekends to learn a new technology (one that is old
           | enough to purchase alcohol in all 50 states---this is not
           | like chasing the latest web framework).
           | 
           | [1] There have been various blog posts about how android is
           | "broken by design" because it expects to configure host IP
           | via SLAAC and receive DNS servers via RA, instead of DHCPv6.
           | This is utter nonsense.
           | 
           | [2] Android did, until about 5 years ago, not like to use DNS
           | servers with ULA prefixes (the IPv6 equivalent of IPv4
           | private network ranges). That's unfortunate, but hardly a
           | "dumpster fire".
        
             | yjftsjthsd-h wrote:
             | > Good IPv6 host support has been a thing in almost all
             | consumer OSes for over 10 years now. All currently
             | supported versions of Windows, MacOS, Android[1][2] and iOS
             | support IPv6 natively.
             | 
             | You probably need to care about the last couple unsupported
             | versions, too; 5-year-old Android versions are still in the
             | wild. Thankfully, it's a rolling window and the stuff with
             | poor support _is_ dropping off.
             | 
             | > The problem is simply that some people don't want to
             | spend a couple weekends to learn a new technology (one that
             | is old enough to purchase alcohol in all 50 states---this
             | is not like chasing the latest web framework).
             | 
             | The problem, speaking as someone who spent some weekends
             | worth of time on it, is that the technology, which has only
             | been _relevant_ for the last handful of years regardless of
             | when it was first released, is _not_ nearly that simple and
             | works just differently enough to trip you up. (And you can
             | 't just do a full replacement and drop v4, so the
             | differences will _keep_ tripping you up)
        
           | WorldMaker wrote:
           | As far as we can tell from aggregate statistics, consumer
           | devices have been leading IPv6 adoption, not lagging it.
           | 
           | Charts of IPv6 usage such as Google's tend to still show a
           | strong "bathtub curve" with a very noticeable decline during
           | 9-5 work hours making a pretty clear case that
           | corporate/enterprise devices are the ones (greatly) lagging
           | behind.
           | 
           | Consumer devices most directly feel the effects of NAT/CGNAT
           | and feel much more pressured to route around that IPv4
           | "damage" with IPv6. Some consumer networks, especially mobile
           | carriers in every part of the world, have moved to
           | IPv6-predominant (if not "IPv6-only"; depending on how you
           | feel about IPv6 to IPv4 gateways). The "Happy Eyeballs"
           | algorithm has been in play on most Consumer OSes for several
           | years now and consumer devices generally _strongly_ prefer
           | IPv6 services over IPv4 when given a dual-stack choice.
        
             | kevin_thibedeau wrote:
             | There are a ton of IP connected devices that aren't running
             | a sophisticated OS. IPv6 may not be available or, even if
             | it is, the codebase is fossilized around handling and
             | storing IPv4 addresses.
        
           | toast0 wrote:
           | My sample size of two DSL modems that my ISP supports says
           | yes. The old one would reboot if it received a fragmented
           | IPv6 packet. The newer one is better, it doesn't crash, it
           | just delays more or less all packets for a second if IPv6 was
           | in use.
           | 
           | Wireless router support for IPv6 is iffy too, from what I've
           | heard.
        
           | creeble wrote:
           | It's pretty hard to tell how many "devices" are capable of
           | ipv6 because they typically just ask for ipv4 DHCP addresses
           | and get them from routers.
           | 
           | My guess is that it is still a tiny minority of non-computer
           | devices that will use ipv6 on the LAN side of a router.
        
             | lanstin wrote:
             | At my house with about 10 online devices now i have 42 ipv6
             | entries in the nat table out of 272 total. I have at&T adsl
             | but would see similar results with Comcast business (which
             | i had until a month ago). I have either linux or newish
             | commercial devices and they have slipped ipv6 in over the
             | past few years. no more HE tunnels for me. I suspect if
             | more websites put it in the DNS it would just work. I am
             | just waiting for ipv6 only VPCs in AWS.
        
             | dsr_ wrote:
             | I have a properly set up house network with IPv4 and IPv6
             | support infrastructure. In December, we used 1.22 TiB total
             | traffic, of which 722.96 GiB was IPv6.
             | 
             | IPv6 traffic has been at least 50% for at least the last
             | year (based on the most convenient statistics I can grab).
        
       | ngcc_hk wrote:
       | The fundamental problem of v6 is that it is not a simple
       | extension of v4 in a practical manners. Too many add-on concerns
       | like security. Should have fit it on v4 as well.
       | 
       | Good luck.
        
         | api wrote:
         | What are the security concerns with V6 that don't exist with
         | V4?
        
           | chungy wrote:
           | I'm guessing OP is under the impression that IPsec is
           | mandatory in v6. There was an intent in the 1990s to do
           | exactly that, but it was recanted.
        
           | jandrese wrote:
           | Also, this ignores the fact that IP address scanning is
           | tremendously harder on IPv6 than it is on IPv4. That's a
           | significant security improvement right off the bat.
           | 
           | All of the dozens of Internet bots that try to portscan my
           | router every day would cease to be an issue if I could turn
           | off my IPv4 address.
        
           | yardstick wrote:
           | Not the op, but there are basic things like having to enable
           | privacy addresses otherwise you expose your MAC in your IPv6
           | address.
        
             | immibis wrote:
             | Then operating systems shall start shipping with that
             | option enabled by default.
        
               | yardstick wrote:
               | Yes, and it's additional overhead for the people
               | designing the operating system to worry about. More
               | complexity, more attack surface.
        
               | icehawk wrote:
               | They already do, both the mac and windows computers on my
               | desk have it enabled.
        
             | api wrote:
             | This can be fixed not only with privacy addresses but also
             | with DHCPv6 instead of SLAAC. The use of the MAC in this
             | way was a bad bit of design but it's easily remedied. There
             | is nothing in IPv6 that mandates that addresses be assigned
             | this way. Like IPv4 they can be anything.
             | 
             | I personally like stuff like :feed:cafe:babe:beef or
             | :dead:d00d :).
        
               | yardstick wrote:
               | I agree they can be fixed, although I disagree that
               | DHCPv6 is the solution given Android doesn't support
               | DHCPv6. In practice most vendors I know of just use
               | privacy addresses by default now for IPv6, at least
               | outside servers, so it's mostly a non-issue but the fact
               | remains it's something not applicable to IPv4. And for
               | quite a while it was an issue, it's just that IPv6 hasn't
               | been popular enough for consumers to care instead of just
               | security people.
               | 
               | > There is nothing in IPv6 that mandates that addresses
               | be assigned this way. Like IPv4 they can be anything.
               | 
               | Yes but that's nitpicking at the core RFCs vs the many
               | other supporting RFCs. There's no IPv4 RFC for using a
               | MAC in the IP address, whereas there is with IPv6
               | (rfc2373 from a quick look, maybe others).
        
               | yjftsjthsd-h wrote:
               | Sure, you can fix it, but you have to fix it; with v4 it
               | just wasn't a problem.
        
             | staticassertion wrote:
             | Is exposing a MAC a considerable issue? Also I feel like
             | you can randomize your MAC easily enough.
        
         | stephen_g wrote:
         | This is a common misconception. Apart from the kind of NATs we
         | have now, there is no way that IPv4 could have been expanded. A
         | lot of routing hardware was ASIC based (I'm sure plenty still
         | is), so packet headers were fixed and couldn't be changed
         | without changing all the routers. Just like they had to be
         | changed with IPv6. Any server would need to understand the old
         | system and the new system simultaneously to be able to be
         | backwards compatible - just like with dual stack now. Big parts
         | of the internet wouldn't be reachable until the host, the
         | server, and every router and middle box along the path had been
         | upgraded. Just like with IPv6.
         | 
         | So you'd have all the same problems, just in a slightly
         | different way...
        
           | magicalhippo wrote:
           | > his is a common misconception. Apart from the kind of NATs
           | we have now, there is no way that IPv4 could have been
           | expanded.
           | 
           | The misconception is that IPv4 could have been expanded in a
           | compatible way. That's not GP's point though as I read it.
           | They could have made an incompatible IPv5 which was exactly
           | like IPv4, except with additional address bits.
           | 
           | Then the operational side would be similar, and you wouldn't
           | have to learn everything over again.
           | 
           | Instead they changed just about everything.
        
             | Nursie wrote:
             | I wonder if it's perhaps time to write off IPv6, for this
             | reason, and come up with a different standard that is more
             | like that.
             | 
             | Because we're decades in here, and it's still not dominant,
             | for the reasons given.
        
               | p_l wrote:
               | You would start from scratch to develop chips that would
               | support your new formats.
               | 
               | IPv4+TCP and IPv6+TCP is literally baked into hard
               | silicon on many, many devices, even if not for all phases
               | of the protocol. We're talking redesigning switching
               | chips, redesigning TCAM (content-addressable memories
               | used to cache routes), etc. on top of designing yet
               | another protocol.
               | 
               | At least old IPv9 had the benefit of some level of
               | support in sw/hw when it was proposed (as it reused CLNS
               | from OSI for internetwork protocol)
        
               | IshKebab wrote:
               | Based on this
               | 
               | https://www.google.com/intl/en/ipv6/statistics.html#tab=i
               | pv6...
               | 
               | we're probably 15-20 years away from "enough people have
               | IPv6 that you can start dropping IPv4". There's zero
               | chance you could make an IPv5 and have any adoption at
               | all in that time.
        
             | WorldMaker wrote:
             | If you are going to _have to_ break backward compatibility
             | anyway, of course you are going to use that as a chance to
             | change other things, fix some things that weren 't broken
             | but weren't great either, try for some nice to haves while
             | you are at it.
             | 
             | Especially if you were predicting a migration across any
             | compatibility break would take decades or more (or
             | potentially forever live side-by-side), there's very
             | pragmatic reason "rip the bandaid off" and to change
             | everything _all at once_ rather than make a series of far
             | more painful  "smaller" migrations that would each
             | individually take nearly as long.
        
             | xxpor wrote:
             | >hey could have made an incompatible IPv5 which was exactly
             | like IPv4, except with additional address bits.
             | 
             | That exists, it's called enhanced IP or something. I'm
             | having trouble finding it now since it's been a few years,
             | but I've had a customer using it. Of course nothing besides
             | the endpoints understood it, so it had to be wrapped in
             | UDP. Horrible.
        
             | jandrese wrote:
             | IPv6 isn't that different than IPv4. Neighbor Discovery is
             | just ARP. Not having in-path fragmentation and loads of
             | other IPv4 legacy crap is a good thing.
             | 
             | The only major change is that instead of the smallest
             | routeable unit being a single address the smallest unit is
             | now a whole 64 bit subnet so hosts have a bunch of bits
             | they can use for various purposes. Network administrators
             | don't have to worry about that for the most part, the hosts
             | figure that out on their own.
             | 
             | I guess there might be a security implication if someone
             | has built their security system around knowing everything
             | on the network via DHCP. But that was always a mistake. If
             | you want real security you need to use 802.1x or similar.
             | Being told you can't use DHCP to secure your network
             | anymore is probably shock to some admins, but hopefully
             | they take the opportunity to reconsider their system from
             | the ground up.
        
       ___________________________________________________________________
       (page generated 2022-01-21 23:01 UTC)