IPv6, point to point links, and subnet lengths

December 2, 2016

One of the things that my recent IPv6 work has given me is plenty of what we call 'learning experiences'. The latest one concerns a little detail of what I wrote earlier, where I casually said:

[...] I discovered my next configuration mistake, which was the subnet length on my IPv6 address configured on my DSL PPPoE link; for reasons lost in the depths of history, it had been configured with a /64 subnet length instead of being set to be a single IPv6 address. [...]

After I found and fixed that, at last everything worked [...]

That turned out to be a little bit optimistic.

In Linux IPv4 networking, you can definitely have the same IPv4 address attached to an Ethernet interface, with a /24 netmask, and to a point-to-point link, as a /32 single address. I have essentially this setup today on one machine with my IPSec tunnel. This works reliably and I've never had any problems with it.

As far as I can tell, this is not true of IPv6 on Linux. I believe that some of the time you can do this, because I'm pretty sure that I managed to do it at the time that I wrote that first entry. However, some of the time it appears that you can't, or at least I can't; if I have a given IPv6 address on an Ethernet interface as a /64 and I try to put it on a PPP interface as a /128, it quietly gets converted into a /64 (and then things explode, as before). This state seems to be at least somewhat sticky, in that I couldn't fix it with manual use of the ip command; instead I got various puzzling error messages (which I neglected to write down, because I was focused on solving the problem instead of writing a blog entry).

(I think it may have been 'RTNETLINK answers: Cannot assign requested address' when I was trying to delete the /64 IPv6 off the PPP link. In hindsight, maybe this meant that parts of the system thought it wasn't a /64 and parts felt otherwise.)

Since IPv6 addresses are extremely plentiful, my solution was simple; I just gave my inside Ethernet interface a different IPv6 address in my /64. This seems to have made everything happy, although it made me shuffle a few things around in my overall configuration; I changed Unbound to listen on this IPv6 address instead of the PPP one, and then I changed radvd to give out this address as the RDNSS address. My PPP link now has my 'router' IPv6 IP as a /128, my Ethernet has a /64, and things still do SLAAC and can talk to the world via IPv6.

(In thinking about it, possibly things would have worked just as well without changing the Unbound IPv6 address. After all, the 'router' IPv6 address is still perfectly reachable, it's just not the address associated with the Ethernet interface.)

One of the things I've discovered as a result of this is that I don't actually understand how IPv6 interacts with point to point links. A conventional IPv4 PtP link is intrinsically unicast to the peer IP; there is nothing else there, so a netmask doesn't really make sense in general. This is clearly not how my IPv6 PPP link is working; for a start, ifconfig and ip don't list a peer IPv6 address (and the link has a link-local IPv6 address too).

In fact now I wonder if my PPP link needs to have a public IPv6 address associated with it at all, or it's enough to have my default IPv6 route pointed through it. In the old days I had to put my public IPv6 address on the PPP link because I wasn't putting it anywhere else, but that's not applicable now that I'm also putting an IPv6 address on my Ethernet interface.

(Some brief testing suggests that it doesn't need a public IPv6 address. So it may be that I have been doing this totally backwards from the start and I'm now very slowly and incrementally evolving my configuration towards what it should be to be proper.)

I once did some reading about how IPv6 worked, but clearly not enough of it stuck in my head. I should probably do it again, although it's hard to feel motivated to take another slog at a large block of information that didn't stick well enough the first time around.

Written on 02 December 2016.
« I suspect that lots of IPv6 hosts won't have reverse DNS
One reason why rogue wireless access points are a bigger risk at universities »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Dec 2 00:34:43 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.