I noticed that I have the IPv4 only for the sake of talking to wolfery on my test vm; if it’s not much of a hassle on your side @Accipiter, can you get ipv6 going?
1 Like
That’s probably up to the capabilities of the hosting provider (which probably needs to change mumble mumble).
Obligatory note: I am not a wolf.
1 Like
Yeah, but it seems the current hoster offers ipv6 on all the plans which makes me think it’s either the DNS missing or the wolf never setting up the ipv6 stack.
1 Like
suddenly remembers the weird details of the host’s routing
Oh yeah, they do. Hmm!
1 Like
Semi-back!
I have little experience in setting up IPv6.
I’ve added a AAAA record for the DNS of mucklet.com, to try to see if I can get it to work on test.mucklet.com . But trying to ping using ping6, I get:
Destination unreachable: Address unreachable
I’ll look into it a bit more. 
1 Like
Feel free to poke me if you need any help in sorting that out.
1 Like
$ dig mucklet.com AAAA +short
fe80::5054:ff:fe9e:e4f7
That’s the link-local address (like 127.0.0.0/8 for ipv6) 
1 Like
Haha, oh bummer 
. Shows you how much I know about IPv6 
1 Like
If your linux box comes with ipv6 configured (and it’s just the dns issue) it’d come up in
ip -6 a s eth0 # or however the eth interface is called.
You’d be looking for the one marked scope global.
1 Like
I get:
~$ ip -6 a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::5054:ff:fe9e:e4f7/64 scope link
valid_lft forever preferred_lft forever
So, I don’t seem to have any external one then. I guess I need to contact the host provider then.
1 Like
Yep. Not sure if you’re getting yours from inleed.se or any reseller (RIPE says the IP’s inleed’s for what I know), and all their plans seem to say they have ipv6 /64 subnet. Must be a configuration issue.
1 Like
A brief checklist of things that come to my mind:
- make sure your IPv6 is routable (that is get your IP on the box, make sure pings work)
- make sure your nftables/ip6tables are tuned accordingly: the rules for those are different, make sure you’re not accidentally exposing something you don’t want on IPv6 because you thought you cut it out in iptables only for it to bind to dual-stack
- make sure your docker have an ipv6 subnet and it’s configured properly.
- and that your app listens on dual-stack
- and DNS AAAA record (that’s easy, but remember, it’s always dns)
it’s funny how it’s 2022 and we still have problems with ipv6 adoption.
2 Likes
It’s because they second systemed it into unusability.
And we got the simplified version.
1 Like
it’s because /64 is the minimum allowed subnet so all they give you is /64. There’s no reason you can’t get a larger network, ffs, tunnelbroker.net gives you a /48 for free because there’s that many IP addresses. But no, it’s /64 so you get to come up with all the crazy ndp hacks and whatnot.
1 Like
That’s downright contrary to the RIPE suggested allocation of a /56 per user. Sane practices programmatically speaking though, is aiming for stack indifference on whether it is communicating on IPv4 or IPv6.
1 Like
this one? they do discuss /64s in the same document and the reasoning is that the customer subnets show be /64. Now, it’s on one hand somewhat reasonable that you get one whole subnet per one host. At the same time it makes a bunch of things trickier in the modern world of containers; specifically having to split the minimal subnet further down and bother with how NDP is routed. For a VM host it’s reasonably straightforward to just bridge the VMs on the main interface and roll with it.
This, of course, only concerns the low budget setups. Anything else and you will just get an IPv6 block from PI space and set up peering for your AS. Probably.
Either way it’s a world of pain.
1 Like
Relevant part:
It is strongly discouraged to assign prefixes longer than /56 unless there are very strong and unsolvable technical reasons for doing this.
There are enough IPv6 addresses to delegate end-users a /48, so a /56 already represents a sizeable restriction. There is no need to delegate fewer addresses than that, so if your IPv6 allocation is insufficient to provide a /56 to each end customer (remember there are 134 million /56s in a /29 and 16,7 million in a /32), explain to your RIR that your initial allocation was too small and that you require a larger allocation based on your IPv6 implementation plan. Offering less than a /56 can be feasible if just a /29 is allocated and 6RD is being used, as an IPv4 address is embedded in the IPv6 prefix. However, even in this case, a larger allocation from your RIR can be justified and the transition protocol allows other ways to sort it out.
Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs. With a single /64, the end customer CPE will have just one possible network on the LAN side and it will not be possible to subnet, assign VLANs, alternative SSIDs, or have several chained routers in the same customer network, etc.
1 Like
I tend to think that part refers to the customers in a sense of the last mile: the broadband users and whatnot. When you rent a single box in a DC you generally don’t have a customer LAN behind it in the same sense of having multiple devices.
1 Like
Most (from my sample size of 3 dedi hosts) do give a prefix delegation, at least on request. That is usually a /56, but some even provide a /48. 64s to VPS servers, I can understand.
1 Like
Any of them in EU? I’d been evaluating my options for changing the hosters recently.
1 Like