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