In reply to a post by David_W2:

The problem with IPv6 is how slowly the rest of the Internet has adopted it and how many devices and services still support only IPv4. All my end-user devices, servers, switches, wireless APs, and my main HP MFP support IPv6, but nothing else does (solar inverter, a couple of label printers, a network scanner, and various IoT devices). Vodafone still does not offer IPv6, so most of the time when I am away from home, I can only VPN into my network using IPv4. My backup ISP, Virgin Media, still has not enabled IPv6 in my region.

For several years now, IPv6 has been a criterion on my equipment purchases and is becoming a criterion for connectivity purchases too . The label printers and the network scanner probably don't need external connectivity, so lack of IPv6 may not be such a big issue.

But a solar inverter with only IPv4 is a pretty poor show, given that it is a relatively high cost item and IPv6 is not going to erode the margins much. As for IoT, OK the margins are a lot tighter for the cost of IPv6, but bearing in mind that the prospect of IoT was one of the drivers for IPv6, that is rather hard to understand.

We are being squeezed between the indolence of the likes of Virgin and Vodafone, the margin chasing of IoT suppliers and the greed of Zen.

In reply to a post by David_W2:

CG-NAT is totally unsuitable for me; I need incoming IPv4. I cannot rearrange everything into a /32, as that would leave me with clashing ports. I will try to rearrange my network into a /29 over the next few days, as running with the fewest possible IPv4 addresses makes sense.

CGNAT was only ever a stop gap, which has worked slightly too well for the major use case of browsing the web. I think your rearrangement to a /29 is also a stop gap and it is time for everyone to start scrutinising the market a bit harder for IPv6 solutions

I hope that BTW has got its systems fixed. When my IP4 allocation was changed by my ISP a year or so ago, BTW’s systems took the instruction to be a cease service request. It took BTW over 10 days to fix their software with no service during this time.

In reply to a post by DFScale:

For several years now, IPv6 has been a criterion on my equipment purchases and is becoming a criterion for connectivity purchases too . The label printers and the network scanner probably don't need external connectivity, so lack of IPv6 may not be such a big issue.

But a solar inverter with only IPv4 is a pretty poor show, given that it is a relatively high cost item and IPv6 is not going to erode the margins much. As for IoT, OK the margins are a lot tighter for the cost of IPv6, but bearing in mind that the prospect of IoT was one of the drivers for IPv6, that is rather hard to understand.

We are being squeezed between the indolence of the likes of Virgin and Vodafone, the margin chasing of IoT suppliers and the greed of Zen.

Like you, I would love to move to an IPv6-only network, with IPv4 used only locally for legacy devices like label printers. However, the real world situation today makes this impossible..

Try finding an IPv6 DECT SIP base - I am not sure anyone makes them. Unless something has changed very recently, even the latest equipment from Gigaset (one of the better manufacturers of VoIP phones) is still IPv4 only. SIP is notoriously NAT-hostile, and all the workarounds (STUN, SIP proxies, B2BUA or a full-on SIP PABX like Asterisk) have drawbacks. Zen's SIP service is IPv4 only anyway. A&A's SIP service supports IPv6, but the lack of IPv6 client devices makes this difficult to use at present. At least A&A have tried - there is an IPv6 SIP service in the UK if you have a suitable client device to take advantage of it.

Thankfully, some other NAT-hostile protocols are gradually fading away. In particular, the insecure and NAT-hostile FTP is gradually being replaced by SFTP or self-hosted "cloud" storage such as OwnCloud. However, I have two very expensive Sony camera bodies; both are IPv4-only, and only the newer one has an SFTP client; the older one has only an FTP client.

The solar inverter has a connectivity dongle - there's a USB socket on the device onto which the dongle connects with a weatherproof connector. I would be happy to upgrade the dongle to one that supports IPv6, but the manufacturer doesn't make one. My workaround here will be to install a network to RS-485 bridge for most purposes - but, again, finding a suitable bridge with IPv6 support is somewhere between difficult and impossible, especially once you start throwing in constraints like PoE support. I cannot completely do away with the IPv4 cloud functionality of the solar system, as that is how firmware updates are delivered, the clock remains synchronised, and is also the only way to access some important scheduling functions that are not available via RS-485.

IoT is just a mess; I don't have a single IoT device that has IPv6 support. Manufacturers are too used to creating new products using the same IPv4-only network stacks that they have used for years, while consumers typically cannot cope with the complexity of static IPv6, nor do many consumer routers support DHCPv6. I am familiar with IPv6; I debugged the IPv6-over-PPP code in pfSense back in the day, and contributed the patches that made it work reliably.

Matter is IPv6-only but still throws up early-adopter challenges. ESPHome now has rudimentary IPv6 support, but you have to run dual-stack, and address allocation uses SLAAC based solely on the MAC address, so it is not RFC 7127-compliant. A project on my to-do list is to replace the horrid Tuya-based IoT module in a heat pump with one running ESPHome; fortunately, the control board has a well-documented RS-485 interface.

There are some parallels between the current situation with IPv6 and the historic challenges in getting people to secure Wi-Fi networks; consumer routers and APs were supplied insecure by default so that end users could get them working quickly without needing technical support. However, at least the Wi-Fi gear could be configured for secure operation (well, up to a point - WEP was never secure and the original WPA was less than ideal) if you wanted. You cannot configure a device that doesn't support IPv6 to use IPv6.

I will continue trying to buy products with IPv6 support, but expect that this will remain difficult for some time. For example, I am not sure whether any mainstream EVSE (EV "charger") brands support IPv6.

In reply to a post by DFScale:

CGNAT was only ever a stop gap, which has worked slightly too well for the major use case of browsing the web. I think your rearrangement to a /29 is also a stop gap and it is time for everyone to start scrutinising the market a bit harder for IPv6 solutions

I cannot buy what is not available. End users cannot hope to resolve the current "chicken and egg" situation of IPv6 today. Consumer ISPs and mobile networks don't want to enable IPv6 in case it breaks things for their customers or creates excessive workload for support teams. The IoT companies will not support IPv6 unless they are forced to - to my mind, the only real hope here is legislative action by the European Union, as happened with the EU's requirement that USB-C is the standard charger for wireless devices. As you say, much of the problem is that CG-NAT has worked too well.

Maybe rearrangement to a /29 is another stopgap on my part, but it is the best that I can do right now. I am doing my best to re-engineer everything locally to support IPv6 and conserve IPv4 address space (for example, by deploying NGINX as a reverse proxy). I am leery of solutions such as Cloudflare tunnels; who is to say they will not start charging in the future?

I am tired of all the sticking plasters to keep IPv4 going. However, until the IPv6 situation improves, I need at least two public IPv4 addresses to avoid breaking things on my network.

In reply to a post by David_W2:

I cannot buy what is not available. End users cannot hope to resolve the current "chicken and egg" situation of IPv6 today. Consumer ISPs and mobile networks don't want to enable IPv6 in case it breaks things for their customers or creates excessive workload for support teams. The IoT companies will not support IPv6 unless they are forced to - to my mind, the only real hope here is legislative action by the European Union, as happened with the EU's requirement that USB-C is the standard charger for wireless devices. As you say, much of the problem is that CG-NAT has worked too well.

Since I have started my IPv6 procurement policy, the things I wanted all came with IPv6. And I have not needed to pester suppliers. But to make that change, I think we need to be prepared to bother them with things like "Will you be upgrading this product to IPv6?" and "I need IPv6 to access this remotely, because I have CGNAT on IPv4" ie to build up to it being more of a pain not to support IPv6.

Most gadgets now run some form of Linux and IPv6 dual stack is built in, so the decision point for manufacturers is when they up version Linux - at that point they need to feel it is more of a hassle to take IPv6 out than to leave it in.

In reply to a post by David_W2:

Maybe rearrangement to a /29 is another stopgap on my part, but it is the best that I can do right now. I am doing my best to re-engineer everything locally to support IPv6 and conserve IPv4 address space (for example, by deploying NGINX as a reverse proxy). I am leery of solutions such as Cloudflare tunnels; who is to say they will not start charging in the future?

I am tired of all the sticking plasters to keep IPv4 going. However, until the IPv6 situation improves, I need at least two public IPv4 addresses to avoid breaking things on my network.

You are right to be wary of sticking plasters such as tunnels and 4 to 6 and 6 to 4 protocols. Dual stack [and possibly IPv4 over IPv6] ISPs together with dual stack or IPv6 only devices is where we should be right now.

In reply to a post by DFScale:

Most gadgets now run some form of Linux and IPv6 dual stack is built in, so the decision point for manufacturers is when they up version Linux - at that point they need to feel it is more of a hassle to take IPv6 out than to leave it in.

It depends on the gadget. I agree with what you say about anything running Linux. However, many IoT devices use microcontrollers that run a framework such as ESPHome, an RTOS like FreeRTOS, or even run on bare metal with manufacturer-supplied libraries. For all these devices, adding IPv6 support can be much harder than flipping a few configuration switches and upgrading the Linux kernel. Some of these microcontroller-based devices are significantly resource-constrained and lack the additional resources needed to run dual-stack.

A further challenge to implementing IPv6 on battery-powered IoT devices is that consumer switches and wireless access points often lack effective MLD snooping (and devices that do offer good MLD snooping are often not configured correctly), causing IoT devices to waste power dealing with unnecessary IPv6 multicast traffic. You cannot run IPv6 with multicast disabled unless you want to break important things, such as router discovery.

Same here, had an email end of June telling me that the /29 block I've had since 2015 is being removed, I've just renewed my contract with them and if I'd known this was coming I'd have gone elsewhere. I actually run my own servers including email server and use the whole allocation.

This is bad form from Zen and quite disappointing, I'll bide my time until the end of the contract and find another provider, I won't be recommending Zen to potential business customers any more either.

In reply to a post by robaltech:

Same here, had an email end of June telling me that the /29 block I've had since 2015 is being removed, I've just renewed my contract with them and if I'd known this was coming I'd have gone elsewhere. ... I'll bide my time until the end of the contract and find another provider, I won't be recommending Zen to potential business customers any more either.

I would argue that this is a material change of contract and you should be allowed to move ASAP without penalty.

In reply to a post by David_W2:

I need incoming IPv4. I cannot rearrange everything into a /32, as that would leave me with clashing ports.

I originally had a /30 with Cerberus, but I reconfigured to work on a single /32 when I moved to Aquiss. It can be made to work really well.

(1) For incoming web: I use sniproxy on port 443 (and port 80 for http->https redirects) This inspects the SNI information in the client hello, and forwards the request to the correct backend server.

In the DNS I put an AAAA record pointing directly at the target server, and an A record pointing at sniproxy. This way, if the client is IPv6-capable it bypasses the proxy. But either way, the TLS encryption is end-to-end (the proxy does not have any certificates, nor does it decrypt the traffic).

In order for the target server to see the source IPv4 address, depending on the server, I either enable Proxy Protocol in the proxied connection, or I embed the source IPv4 address in the new IPv6 source address - small patch required.

(2) For incoming authoritative DNS I use dnsdist. It looks at the domain and forwards to the appropriate back-end DNS server.

External secondaries are all IPv6-capable so they can AXFR directly anyway.

(3) I don't do incoming SMTP, but if I did, a mail gateway on port 25 could route mail accordingly. (And/or sniproxy could handle port 465; it's not limited to HTTPS)

(4) For ssh, I don't have hosts listening on port 22 anyway - too much noise from port-scanners. A few have dedicated ports which are port-forwarded. To ssh into an arbitrary host, I can either -J (jumphost) via one machine exposed to the outside, or use wireguard.

Previously I port-forwarded a UDP port for wireguard, but now this runs directly on the router.

Your requirements may well be different to mine, but for me it works really well, and has been an interesting project to prove that you *can* run a network happily on a single IP, even with lots of servers and VMs behind it.

In reply to a post by candlerb:

Your requirements may well be different to mine, but for me it works really well, and has been an interesting project to prove that you *can* run a network happily on a single IP, even with lots of servers and VMs behind it.

My requirements are rather different, but you describe the direction of travel I was already taking. I have been gradually re-engineering everything into a properly virtualised and containerised environment, making as much use of proxies and other IPv4 address-space-sparing techniques as possible.

I use VPNs (in my case, NAT-T capable IPsec) for high-security external traffic and do not expose SSH directly to the Internet; you have to VPN in to access SSH. I host all primary DNS outside my network.

My problem is that I cannot complete a long-term project with 30 days' notice from Zen, on top of my existing commitments.

Hi,

In reply to a post by zeb99:

Just for info, Zen are inflexible and couldn't possibly delay this change. This is the message I got back from them:

We periodically review how our IPv4 address space is allocated to ensure it is managed effectively across our network and customer base.

As part of this ongoing programme, we are working to standardise and simplify legacy allocations. This approach helps us improve efficiency while ensuring that customers continue to have the address capacity they need to support their services. There is no way we can delay this. Please accept my apologies.

For existing consumer customers who currently have multiple IP addresses free of charge, if they wish to retain those IPs, we can arrange for an order to be placed so the addresses can continue to be provided on a paid basis. This allows us to maintain the service while balancing commercial considerations and helps avoid any disruption to the customer experience.

We currently offer the following options:

1 IPv4 Address – Included in your tariff
8 IPv4 Addresses – £13.20 per month (including VAT)
16 IPv4 Addresses – £28.20 per month (including VAT)
32 IPv4 Addresses – £58.80 per month (including VAT)
64 IPv4 Addresses – £118.80 per month (including VAT)

If you would like to proceed, please let us know which block size you require and we can arrange this for you.

Seems like they're just money grabbing. Aquiss will do a /29 at extra cost (but less than Zen) and include a /56 IPv6. As soon as things are more convenient timing wise, I will be off from Zen as they've burned their bridges.

I had a /29 from the outset as part of my service (it's listed in the original order confirmation), they now seem to be implying that this was a freebie that now needs to be paid for. I am long out of my minimum term, if I wasn't then I would consider this a material change and a good reason to end the contract without penalty.

Which department were you communicating with which gave you this clarification please?
Do you know which department makes the change?
If you pay for the allocation, is it a new 18 month contract?

thanks