<div dir="ltr">Thanks for your response, it helps me understand things better.<br><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 1, 2023 at 1:39 PM Simon Kelley <<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm not sure there's much incentive to change this: it's not as if <br>
addresses are scarce in the IPv6 world.<br></blockquote><div><br></div>Well, it may not be the most necessary change, but I don't think the reason has as much to do with the plentiful address space. I think it makes the interface complex.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The most clear complication is having to advise the recipient of a prefix that there's a little bite taken out of it, I have to say, "yeah it's ::2/64, but not ::1," where the latter is in a manual somewhere. I have received networks with little bites taken out of them here and there, and each such scheme I have to account for, because I can't re-delegate slices of it freely, if there is a conflict and other layers do things with the traffic. For example, I recently was working with a vendor, and they punched out three holes in their static route for my prefix: two for VARP, one for a gateway. It's not that this can't be sustained, but I have to itemize the holes out-of-band for each such strategy. Rinse and repeat for other vendors or software stacks.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Thankfully, there are norms suggesting IPv6 networks shouldn't use :: or ::1 if they can help it, and although I use link local addressing for the gateway, I suppose having dnsmasq's recursive resolver and DHCP server at ::1 is "close enough" to the intended norm. So I suppose I could use that.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The second problem, related to the first, but more subtle, is how an interface with an address assigned within the network affects Linux.  Here's an example of a network situation that works with, static configuration, for example, in a virtual machine's network namespace:<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"># ip -n vm57nhjf -6 a<br>2: vethivm57nhjf@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000<br>    inet6 2a01:4f9:2b:35a:c6dd::/80 scope global <br>       valid_lft forever preferred_lft forever<br>    inet6 fe80::b068:43ff:fe48:50e1/64 scope link <br>       valid_lft forever preferred_lft forever<br>3: tapvm57nhjf: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000<br>    inet6 fe80::d487:b2ff:fe66:40cd/64 scope link <br>       valid_lft forever preferred_lft forever</div><div class="gmail_quote"><br></div><div class="gmail_quote"># ip -n vm57nhjf -6 r<br>2a01:4f9:2b:35a:c6dc::/80 via fe80::d028:12ff:feb8:a206 dev tapvm57nhjf metric 1024 pref medium<br>2a01:4f9:2b:35a:c6dd::/80 dev vethivm57nhjf proto kernel metric 256 pref medium<br>2000::/3 via fe80::2ce1:51ff:feb6:c56f dev vethivm57nhjf metric 1024 pref medium<br>fd34:f6d7:d9b1:6c85::/64 via fe80::d028:12ff:feb8:a206 dev tapvm57nhjf metric 1024 pref medium<br>fe80::/64 dev vethivm57nhjf proto kernel metric 256 pref medium<br>fe80::/64 dev tapvm57nhjf proto kernel metric 256 pref medium</div><div class="gmail_quote"><br></div><div class="gmail_quote"># ping 2a01:4f9:2b:35a:c6dc::<br>PING 2a01:4f9:2b:35a:c6dc::(2a01:4f9:2b:35a:c6dc::) 56 data bytes<br>< Hangs, which is expected ><br>^C<br>--- 2a01:4f9:2b:35a:c6dc:: ping statistics ---<br>8 packets transmitted, 0 received, 100% packet loss, time 7151ms</div><div class="gmail_quote"><br></div><div class="gmail_quote">Here what you see is a namespace that receives a /79 (not directly visible), and divides it into two adjacent /80s. The lower /80 is sent into the VM tap device, the higher /80 is processed by the veth on the host (where I, contra norms, use the :: address for now). Pinging the 2a01:4f9:2b:35a:c6dc::, at the bottom of the VM's /80 doesn't get any response  because the VM does not have that address configured (it configures ::2, which returns ping as expected). When pinging the :: address, tcpdump shows ICMP packets going in, but no responses coming out, since the VM doesn't happen to have the address configured. Everything works as expected.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Now, let's adapt for dnsmasq, and allocate an address in-network on the host, say, ::1:</div><div class="gmail_quote"><br></div><div class="gmail_quote">ip -n vm57nhjf addr add 2a01:4f9:2b:35a:c6dc::1/80 dev tapvm57nhjf</div><div class="gmail_quote"><br></div><div class="gmail_quote">Now we get this:</div><div class="gmail_quote"><br></div><div class="gmail_quote"># ping 2a01:4f9:2b:35a:c6dc::<br>PING 2a01:4f9:2b:35a:c6dc::(2a01:4f9:2b:35a:c6dc::) 56 data bytes<br>64 bytes from 2a01:4f9:2b:35a:c6dd::: icmp_seq=1 ttl=64 time=0.059 ms (DIFFERENT ADDRESS!)<br>64 bytes from 2a01:4f9:2b:35a:c6dd::: icmp_seq=2 ttl=64 time=0.080 ms (DIFFERENT ADDRESS!)<br></div><div class="gmail_quote">[...etc...]</div><div class="gmail_quote"><br></div><div class="gmail_quote">Which is not so good: rather than forwarding the ping to the VM to then get no response, we get the reply from the veth, which has a different source address IP entirely. I could slather on some more Linux features to fix this, I imagine, but: complexity.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Pinging the bite of the address space works, though it's handled by the host of course, as does the address the VM listens to:</div><div class="gmail_quote"><br></div><div class="gmail_quote">root@Ubuntu-2204-jammy-amd64-base ~ # ping 2a01:4f9:2b:35a:c6dc::1<br>PING 2a01:4f9:2b:35a:c6dc::1(2a01:4f9:2b:35a:c6dc::1) 56 data bytes<br>64 bytes from 2a01:4f9:2b:35a:c6dc::1: icmp_seq=1 ttl=64 time=0.051 ms<br>64 bytes from 2a01:4f9:2b:35a:c6dc::1: icmp_seq=2 ttl=64 time=0.075 ms<br>^C<br>--- 2a01:4f9:2b:35a:c6dc::1 ping statistics ---<br>2 packets transmitted, 2 received, 0% packet loss, time 1018ms<br>rtt min/avg/max/mdev = 0.051/0.063/0.075/0.012 ms<br>root@Ubuntu-2204-jammy-amd64-base ~ # ping 2a01:4f9:2b:35a:c6dc::2<br>PING 2a01:4f9:2b:35a:c6dc::2(2a01:4f9:2b:35a:c6dc::2) 56 data bytes<br>64 bytes from 2a01:4f9:2b:35a:c6dc::2: icmp_seq=1 ttl=63 time=0.494 ms<br>64 bytes from 2a01:4f9:2b:35a:c6dc::2: icmp_seq=2 ttl=63 time=0.504 ms<br>64 bytes from 2a01:4f9:2b:35a:c6dc::2: icmp_seq=3 ttl=63 time=0.516 ms<br>^C<br>--- 2a01:4f9:2b:35a:c6dc::2 ping statistics ---<br>3 packets transmitted, 3 received, 0% packet loss,</div><div class="gmail_quote"><br></div><div class="gmail_quote">Small note here, you can see the overhead of virtualization here, which tries to batch network traffic together before toggling in and out of the VM, as I understand it.</div><div class="gmail_quote"><br></div><div class="gmail_quote">But, moving onto the address ::3 or any other higher address the VM is not listening for, we get another change in behavior:</div><div class="gmail_quote"><br></div><div class="gmail_quote">root@Ubuntu-2204-jammy-amd64-base ~ # ping 2a01:4f9:2b:35a:c6dc::3<br>PING 2a01:4f9:2b:35a:c6dc::3(2a01:4f9:2b:35a:c6dc::3) 56 data bytes<br>>From 2a01:4f9:2b:35a:c6dd:: icmp_seq=1 Destination unreachable: Address unreachable<br>From 2a01:4f9:2b:35a:c6dd:: icmp_seq=2 Destination unreachable: Address unreachable<br>From 2a01:4f9:2b:35a:c6dd:: icmp_seq=3 Destination unreachable: Address unreachable</div><div class="gmail_quote"><br></div><div class="gmail_quote">It's not an entirely offensive change in behavior, but it is /different/, and somewhat more complex than the former scenario (where packets are forwarded without anything interesting going on in the host) because the tap device has to have a footprint in the guest VM's network and start processing traffic on it.</div><div class="gmail_quote"><br></div><div class="gmail_quote">These are the interesting  transitions I noticed making this change for dnsmasq, and they're somewhat orthogonal to there being a lot of address space in IPv6.</div></div></div>