1 Oct
2017
1 Oct
'17
3:41 a.m.
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