Hi All,
AMPRNET consists of IPv4 addresses 44.x.x.x. Tunnels used to support AMPRNET use
IPv4 hosts as destinations for the tunnels, creating a "mesh-like"
network.
Bent OZ6BL and I have been experimenting with using an IPv6 host to carry
AMPRNET traffic. The reason you might want to do this is that IPv6 addresses,
particularly static addresses, can be much more readily available than with
IPv4. Also, it's an interesting thing to try! We have working tunneled 44.x.x.x
connectivity between three different IPv6 hosts. However, there are some issues that arise, mainly due to the
way in which AMPRNET functions.
Tunneling IPv4 inside IPv6 (ip4in6) is easily done and is well documented. In
Linux, commands like these are all that's needed:
/sbin/ip -6 tunnel add ip6tnl1 mode ip4ip6 \
remote 2001:0DB8:112:35c::5630:6324 \
local 2001:0DB8:1245:5200::ca0c:5902
/sbin/ip link set dev ip6tnl1 up
/sbin/ip route replace 44.145.40.32/32 dev ip6tnl1 src
44.136.170.20
It's very similar to how conventional AMPRNET is set up. However, the first
issue is that with ip4in6 you cant (unlike ip4in4) leave the "remote"
address empty, and then use routing commands to set the destination for
different AMPRNET hosts (you'd be trying to add an IPv4 route to an IPv6 gateway
destination). So there's a scalability problem - you'd need to set up a
different tunnel device for each subnet you communicate with!
The second issue is interoperability - if Alf, Bob and Charlie each only have
IPv6 hosted AMPRNET, and Doug, Ed and Fred have only IPv4, then A, B, and C can
communicate with themselves, as can D,E,F, but the two groups cannot
interconnect from tunneled addresses. Of course, A,B and C could host IP4
tunnels as well, but that would somewhat defeat the purpose! Alternatively, one
or more gateways (G) could host both IP4 and IP6 based tunnels, and route
between the different type of network, a bit like this:
A,B,C <----> G <----> D,E,F
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 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?
So there's plenty to think about....
Steve, VK5ASF