I'm interested in some pointers on a MAP-T configuration
A bit of context...
I use Now Broadband in the UK, and all of a sudden DHCP is giving me a 100.126 address - in the 'shared address space' for CGNAT etc. which therefore is not publicly routable. I've swapped back in the original supplied router and it's giving the same. Consequently, I have a working IPv6 connection but no IPv4. Support can only run through scripts and don't understand any of this, so they have booked an engineer for a site visit (that will not help!), apparently their only way of escalating things.
Having searched extensively, this article suggests that Sky (who are the mother network for Now Broadband) are rolling out MAP-T. So my hypothesis is that they've mistakenly rolled this out to me.
My goal
While my Internet is only semi-functioning I was wondering if I could work out a MAP-T config that would actually work. However, the documentation is very limited! I have installed kmod-nat46t and map modules, had a play with the configuration, but to be honest I have no clue as to how to work out what needs to be in the fields. The best info I could finds was for OpenWrt on Japan NTT (MAP-E) but it is clearly for a different scenario.
Is this something it is realistic to work out, or am I wasting my time? Is there a bit of guidance I've missed, or a strategy I should take? Many thanks in advance for any pointers!
Are you absolutely sure they went with MAP-T and not MAP-E?
From what I know, most ISPs, when migrating to IPv6 from an existing IPv4 infrastructure, typically choose MAP-E (RFC 7597) because it's stateless. This makes it easier to implement as it scales better and have lower resource overhead.
For the customer, with a simple setup, it tunnels IPv4 over IPv6 to an internal IPv4 exit point for internet access. Just be aware that neither MAP-T nor MAP-E guarantees that you will get a public IPv4 address.
Did you talk to your ISP? They want to sell a service, they do need to answer your questions - and yes, I know, most service contacts are beyond useless (pre-sales and post-sales). An alternative would be researching local information about your ISP (ISP support fora, anything with a local focus on your ISPs and its competitors).
In general, the IPv4 address space is exhausted and ISPs -especially newer/ smaller ones- are increasingly moving towards cgNAT-like approaches, either because they don't have enough IPv4 addresses (e.g. mine serves ~1.5 million customers with 32'768 IPv4 addresses… neither good words nor money would get me an IPv4 address) or because they have more lucrative uses for their existing IPv4 stock. If they do provide IPv6 connectivity, that might be a viable alternative (works for me and wireguard, mostly).
Usually there is very little you can do from your side, few ISPs can be convinced by mere client-side configuration changes to do otherwise. But at least some ISPs (albeit not mine) around here can be convinced, if you provide them a convincing explanation why you need a public IPv4 address - others will push you towards a paid IPv4 option or a business contract.
Many thanks for the replies. Much to my surprise, the modules loaded seem to have automatically configured and I'm getting IPv4 connectivity. It's still a 100.126.X.X address, and the ISP-supplied router still doesn't work. It is possible the ISP have changed their configuration, but the most likely explanation is that the 4->6 stuff is just working.
There are a lot of entries in the log like this, in bursts, that suggests it's doing something:
Fri Nov 8 04:36:34 2024 kern.warn kernel: [42526.043527] [nat46] Could not translate v4->v6
Literally the only thing indexed by Google with that error message is the source code for nat46
Just to respond to the points above:
No, I'm not sure it's MAP-T I was just guessing from the ISPReview article set out above. My ISP (NOW Broadband) is part of Sky and they seem to share a lot of the same infrastructure / methods.
I had thought MAP-T was stateless, but only through bits and pieces I picked up reading around - I'm sure you're right.
I did talk to the ISP, but it was someone with zero knowledge and a script. They couldn't connect to the supplied router and that triggers an engineer visit from Openreach who provide a lot of the edge -> core infrastructure. No opportunity for a different escalation path - I did push as hard as politeness allowed!
I also scoured the Sky forums (NOW Broadband have closed theirs!), posted on it (someone told me 100.126.X.X wasn't a private IP address, that's all!), and searched around the issue as much as possible before posting here.
I'm not massively fussed if I don't have a public IPv4 as I have a delegated IPv6 and that works for me, realise others will have different needs. What I don't like is the ISP randomly screwing up my connection! This is clearly a mis-configuration as I wasn't issued with a device that can handle MAP-T
...and for anyone coming across this in future, here were the steps I had to take:
Make sure the Openwrt router itself is configured to use an IPv6 DNS server, otherwise it can't connect to update itself. In my case that meant reconfiguring dnscrypt-proxy2, but it was a trivial change.
Either through Luci or SSL install kmod-nat46 and map
After reboot a new interface appeared to be auto-configured:
...and this was showing on the status page as an additional network connection:
Thanks again for the replies, and a big thankyou to those who designed and implemented these modules...and to everyone making Openwrt the truly awesome software it is.
Glad you got it working, but sorry to hear you still have a private address. If you need a public IPv4 address, you might need to pay for one. There are a bunch of commercial services online that can provide it also using IPv6. As for the IPv4 address, most ISPs use CGNAT, which has its own reserved range from 100.64.0.0 to 100.127.255.255.
Turns out it was actually this bug within the DHCPv6 implementation in Openwrt. It's soliciting a MAP-T/E connection even if the package isn't installed.
Clearly the ISP detected that and switched me over automatically.
Everything has been working for a while - just using MAP-T so it's IPv4 over IPv6 and sharing part of a single IPv4. Is that ideal? No. Can I live with it for now? Yes.
So, this is the timeline as I can make out:
Openwrt bug means any Openwrt router advertises MAP-T/E capability
ISP rolls out their own new routers with MAP capability
ISP switches over any line responding as MAP-capable to that service
Any router advertising MAP capability but not actually possessing it (Openwrt, Unifi) gets their IPv4 connection borked (which is de-facto no Internet connection)
Symptom is getting an 100.X.X.X address from DHCP, which is 'shared address space' that won't route on the public Internet - and no CGNAT - while you get an IPv6 delegated address that does work.
In the case of Openwrt, you just add the MAP package and the router advertising capability is matched by the actual capability
In order to add the MAP package you need to configure an IPv6 DNS server, as your IPv6 connection still works.
As more ISPs do this, more and more people are going to get hit by this. There are two PRs waiting to be merged that will fix this for Openwrt. Appreciate all the hard work of the devs so not hassling!
In my case there is the added confusion that NOW is a sub-brand of Sky and runs on their network, but the MAP-T rollout isn't supposed to affect NOW subscribers, so it's not something they were expecting at all.
