On Sun, Oct 01, 2017 at 07:11:28PM +1030, Steve Fraser wrote: [...]
Could/should amprgw be configured to do this? Or maybe some hosts elsewhere do that function? But it adds complexity to the overall routing setup (and starts to become a more centralised network).
The current amprgw can't be configured to do this; it's a FreeBSD system using a user-space encapsulation engine, not a Linux host using kernel facilities, so none of the commands you used are available on the system. And its connectivity does not currently support IPv6; it's on an IPv4-only subnet at UCSD. It would have to be redesigned and replaced, and probably moved elsewhere.
At the cost of sacificing the independence and survivability of the mesh structure that is the current AMPRNet, one or more central v4 to v6 gateways could be established. I believe it would be too much to expect each of the 600 or so subnet gateways to become "dual-stacked".
The final issue is dissemination of the information - can the portal be modified to support IPv6 hosts, or do we need another mechanism? Can encap.txt be used still? Would facilities such as ampr-ripd and ripd44 need modifications?
The existing portal could be modified to support some IPv6 but I believe it would be difficult. However, as has been mentioned on this list before, the portal is considering a significant redesign and IPv6 could probably be incorporated into that design. It will depend on there being enough volunteers to help build a new open-source portal.
The existing encap file could be twisted to incorporate IPv6 tunnel information - after all, it's just a flat text file - but it would be painful and ugly. Legacy software would break. A more modern way to disseminate the routing information should be chosen.
The pseudo-RIP that the various utilities use is based on encapsulated RIP-like packets that originate at amprgw, so there would be no way to send routing information via IPv6 from there. And RIPv2 doesn't support IPv6, it's IPv4 only.
Summary: there are difficulties. - Brian