Ipv6: Difference between revisions
No edit summary |
mNo edit summary |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 50: | Line 50: | ||
AMPRNET consists of IPv4 addresses 44. | AMPRNET consists of IPv4 addresses 44.0.0.0/9 and 44.128.0.0/10. 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. | 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.0.0.0/9 and 44.128.0.0/10 connectivity between three different IPv6 hosts. However, there are some issues that arise, mainly due to the way in which AMPRNET functions. | ||
<pre> | <pre> | ||
| Line 85: | Line 85: | ||
---- | ---- | ||
'''Conclusion''' | |||
At this time we have come to the conclusion that there won't be a amprnet conversion to IPv6. A new network will evolve. It seems very unlikely hams will need their own allocation as the smallest ipv6 prefix assigned to a residential connection is a /64 subnet yeilding 18,446,744,073,709,551,616 hosts. | At this time we have come to the conclusion that there won't be a amprnet conversion to IPv6. A new network will evolve. It seems very unlikely hams will need their own allocation as the smallest ipv6 prefix assigned to a residential connection is a /64 subnet yeilding 18,446,744,073,709,551,616 hosts. | ||
We just need a means of advertising the ham netblocks (possibly announced by RIP) and automatically configuring filtering ( | We just need a means of advertising the ham netblocks (possibly announced by RIP) and automatically configuring filtering (an iptables whitelist). A DNS to register the ham host in, etc. An ideal situation would be a totally self-service DNS that uses LoTW (Logbook of the World) P12 certificates to authenticate hams, where they could then enter the IPv6 address(es) from their residential connection that are for ham use. | ||
Latest revision as of 17:52, 29 March 2022
IPv6 is an experimental area for hams. Here are a collection of notes and loose development in relation to that.
Back in 1998, Naoto Shimazaki, 7L4FEP described an idea for use of IPv6 over the amateur radio in a document he presented to a TAPR Digital Communication Conference:
IPv6 has huge address space and it supports real-time traffic. IPv6 realize new applications. For example, managing IPv4 address is not easy. It is possible to encode our "call sign" into IPv6 address. It enables us to managing IP address much easier.
In 2012 a few members from the Mesa Amateur Radio Club of Arizona took this to code and announced:
Club Members Jacques N1ZZH and Vinnie N1LQJ have developed a method of embedding a 2x5 (7 Character) callsign plus up to 185 nodes, plus 1 universal bit and three reserved bits in the 2nd octet, and a 16 bit amateur radio identifer at bit 24 of an IPv6 /64 Subnet address. Tools for encoding and decoding amateur radio callsigns, up to 2x4 & 185 nodes, from IPv6 /64 subnets with Universal bit support and Amateur Radio Flag at the 24bit. Experimental RFC to IETF is being submitted for this proposed amateur standard.
http://sourceforge.net/projects/hamv6/
Kevin, N8VNR contacted IANA in February 2011 hoping to get an allocation for the whole of Amateur Radio in the same vein as 44.0.0.0/8 and received this response:
Currently, the only policy we have been given for the allocation of global unicast IPv6 address space is for allocation to the RIRs. We do not have a policy allowing allocation to organisations like AMPRNet. For this reason, we would strongly suggest contacting an RIR for an IPv6 allocation
Kevin says perhaps someone with some more influence could contact them and make our case. He mentions other options include:
- Get an AMPRnet allocation in each of the RIR regions. This has the disadvantage of fragmenting the routing table (one of the things IPv6 was designed to mitigate). There's also no guarantee all of the RIRs would grant such a request.
- Use ULA space. This has the disadvantage of rendering the IPv6 AMPRnet non-globally routeable. Then again, not much of the IPv4 AMPRnet is truly globally routed, with the gateway for the greater Internet being a single machine somewhere at UCSD.
In 2015, Robert, N6DRC coded an encoding method for radio callsigns into numberic identifiers:
This document describes a mechanism for efficiently and reversibly encoding radio callsigns into compact numeric identifiers. It also defines two addressing mechanisms using this numeric encoding: A new adaptive link-layer addressing scheme (HAM-64) intended for use with new link-layer networking protocols like ARNGLL (Up to 12 characters), and an adaptation of EUI-48 and EUI-64 addresses (Up to 8 and 11 characters, respectively) intended for use with existing link layer protocols.
https://github.com/darconeous/ham-addr/
At the 2016 Digital Communications Conference Brian, W9CR gave a presentation promoting the use and support of IPv6 within the amateur community:
A historical overview of legacy Internet protocols and their limitations will be presented here. IPv6 is the internationally recognized standard replacing these protocols. A short introduction to IPv6 and a case for its support in the amateur radio community is lacking. Finally an overview of the coming IPv6 deployment in HamWAN Tampa Bay is presented as a study of deployment for use by radio amateurs. Some background in IPv4 and Internet protocols is assumed.
In October 2017, Steve, VK5ASF posted to the 44net mailing list a message titled Using IPv6 hosts for AMPRNET, which gave some details of some experiments he was performing to tunnel IPv4 inside IPv6:
Hi All,
AMPRNET consists of IPv4 addresses 44.0.0.0/9 and 44.128.0.0/10. 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.0.0.0/9 and 44.128.0.0/10 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
Conclusion
At this time we have come to the conclusion that there won't be a amprnet conversion to IPv6. A new network will evolve. It seems very unlikely hams will need their own allocation as the smallest ipv6 prefix assigned to a residential connection is a /64 subnet yeilding 18,446,744,073,709,551,616 hosts.
We just need a means of advertising the ham netblocks (possibly announced by RIP) and automatically configuring filtering (an iptables whitelist). A DNS to register the ham host in, etc. An ideal situation would be a totally self-service DNS that uses LoTW (Logbook of the World) P12 certificates to authenticate hams, where they could then enter the IPv6 address(es) from their residential connection that are for ham use.