44Net Wiki - User contributions [en]

Services

2019-08-22T01:41:14Z

Kb9mwr:

{| class="wikitable sortable"
|-
! Maintainer !! Service Name!! URL/IP !! Service Type !! Description !! Other Information
|-
| AMPR ||[[Portal]] || https://portal.ampr.org || HTTPS || manage [[Gateway]], [[Encap.txt]] preferences and ampr.org domain entries (domain entry functionality still under development)|| NONE
|-
| AMPR ||Website || http://www.ampr.org || HTTP || AMPRNet Main Page|| NONE
|-
| AMPR ||Wiki || http://wiki.ampr.org || HTTP || This Wiki|| NONE
|-
| AMPR ||[[44Net mailing list]] || http://hamradio.ucsd.edu/mailman/listinfo/44net || HTTP || mailing list discussion|| NONE
|-
| AMPR ||AMPRNet [[Gateway]] (AMPRGW) || 169.228.34.84 || IP and IPENCAP [[Tunnel]]|| main AMPRNet Router|| Gateways use IP Protocol 4 (IPENCAP) to receive traffic via AMPRGW. Allocation must be registered in the [[Portal]] and gateways must run an AMPRNet routing protocol (i.e. [[RIP]]44 or [[munge script]]).
|-
| AMPR ||[[RIP]]44 || provided via [https://en.wikipedia.org/wiki/Broadcasting_%28networking%29 broadcast] from 44.0.0.1 to all [[gateway]]s registered in the [[portal]] || Routing Information (modified RIPv2 protocol) || distributed by main AMPRNet Router to multicast address 224.0.0.9|| 1.) an enabled IPENCAP tunnel, and 2.) [[ampr-ripd]] or [[rip44d]] must be running and properly configured on your registered gateway
|-
| AMPR ||[[Encap.txt]] || N/A || Routing Information (EMAIL/FTP/HTTP)|| routing information for download|| file must be must be parsed by a self-developed [[munge script]]
|-
| Various Operators||[[Ampr.org]] DNS and Reverse DNS (44.in-addr.arpa) ||
(These hosts maintain a copy of AMPR.ORG and the 44.IN-ADDR.ARPA DNS Zones:)
 ampr.org 
ns2.threshinc.com 
munnari.OZ.AU 
a.coreservers.uk 
ampr-dns.in-berlin.de 
(These hosts maintain a copy of AMPR.ORG and the 44.in-addr.arpa DNS Zones. 44/8 hosts may use as recursive/Client DNS servers:) 
gw.ct.ampr.org (44.88.0.1) 
dns-mdc.ampr.org (44.60.44.3) 
n1uro.ampr.org (44.88.0.9)
|| DNS || name resolution services|| zone files can be downloaded from ftp://gw.ampr.org/pub/
|-
| Various Operators||Network Tools||
http://whatismyip.ampr.org 
http://yo2tm.ampr.org/nettools.php 
http://kb3vwg-010.ampr.org/tools 
http://speedtest.ampr.org 
http://n1uro.ampr.org/do.shtml 
|| HTTP|| source IP checker, speed test, Ping, Traceroute, etc.|| NONE
|-
| Various Operators ||Network Time Protocol Server || gw.ampr.org (Stratum 1, US) ntp.vk2hff.ampr.org (Stratum 1, AU) ntp.g1fef.ampr.org (Stratum 1, UK) kb3vwg-001.ampr.org (Stratum 2, US) gw-44-137.pi9noz.ampr.org (Stratum 2) server.yo2loj.ampr.org (Stratum 2) f4gve.ampr.org (Stratum 3) ntp1.on3rvh.ampr.org || NTP|| Stratum 2 Network Time Server - References US, Canadian and Mexican|| AMPRNet hosts have OPEN ACCESS to these time servers
|-
| OH7LZB ||[[AMPRNet_VPN]] || http://wiki.ampr.org/wiki/AMPRNet_VPN || VPN|| [http://en.wikipedia.org/wiki/OpenVPN OpenVPN]-based || You must have a X.509 certificate issued by [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]. ARRL membership is not required.
|-
| N1URO ||AMPRNet/RF faxing || http://wiki.ampr.org/wiki/axMail-FAX || Facsimile || Online IP based Facsimile service. You have the ability to send emergency communications from packet via Fax. || [http://axmail.sourceforge.net axMail-FAX] Sofware is here.
|-
| OH1KK || KiwiSDR Kaustinen || http://44.139.48.2 || SDR-receiver || KiwiSDR receiver located at Kaustinen, Finland · 0-30 MHz · Antenna switch extension · Northern Europe || Experimental. Also available on non-amprnet at address http://sdr.vy.fi
|-
| [http://allstarlink.org AllStar Link] || AllStar || http://allstarlink.org || Linking of repeaters || AllStar Link core network services are provided via redundant datacenters using 44net IP space. || [https://wiki.allstarlink.org/wiki/Main_Page ASL wiki]
|-}

Ipv6

2019-05-13T16:40:47Z

Kb9mwr:

'''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 [http://www.qsl.net/k/kb9mwr//wapr/tcpip/Take_the_Next_Step_with_the_Next_Generation_Protocol.pdf 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 [http://www.wm7rc.org/ 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/ http://sourceforge.net/projects/hamv6/]

----
Kevin, N8VNR contacted [http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority 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 [http://en.wikipedia.org/wiki/Regional_Internet_registry 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 [http://en.wikipedia.org/wiki/Unique_local_address 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/ 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.''

[http://www.youtube.com/watch?v=VfOrF5pssCs Presentation on Youtube]

[http://www.qsl.net/k/kb9mwr//wapr/tcpip/DCC2016-IPV6.pdf Abstract]

----
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.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.

<pre>
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</pre>

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.

Ipv6

2019-05-13T16:39:52Z

Kb9mwr:

'''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 [http://www.qsl.net/k/kb9mwr//wapr/tcpip/Take_the_Next_Step_with_the_Next_Generation_Protocol.pdf 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 [http://www.wm7rc.org/ 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/ http://sourceforge.net/projects/hamv6/]

----
Kevin, N8VNR contacted [http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority 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 [http://en.wikipedia.org/wiki/Regional_Internet_registry 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 [http://en.wikipedia.org/wiki/Unique_local_address 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/ 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.''

[http://www.youtube.com/watch?v=VfOrF5pssCs Presentation on Youtube]

[http://www.qsl.net/k/kb9mwr//wapr/tcpip/DCC2016-IPV6.pdf Abstract]

----
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.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.

<pre>
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</pre>

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 (a 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.

Ipv6

2019-05-13T16:38:51Z

Kb9mwr:

'''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 [http://www.qsl.net/k/kb9mwr//wapr/tcpip/Take_the_Next_Step_with_the_Next_Generation_Protocol.pdf 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 [http://www.wm7rc.org/ 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/ http://sourceforge.net/projects/hamv6/]

----
Kevin, N8VNR contacted [http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority 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 [http://en.wikipedia.org/wiki/Regional_Internet_registry 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 [http://en.wikipedia.org/wiki/Unique_local_address 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/ 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.''

[http://www.youtube.com/watch?v=VfOrF5pssCs Presentation on Youtube]

[http://www.qsl.net/k/kb9mwr//wapr/tcpip/DCC2016-IPV6.pdf Abstract]

----
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.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.

<pre>
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</pre>

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
''

----
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 (a 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.

Ipv6

2017-10-21T03:45:05Z

Kb9mwr:

'''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 [http://www.qsl.net/k/kb9mwr//wapr/tcpip/Take_the_Next_Step_with_the_Next_Generation_Protocol.pdf 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 [http://www.wm7rc.org/ 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/ http://sourceforge.net/projects/hamv6/]

----
Kevin, N8VNR contacted [http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority 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 [http://en.wikipedia.org/wiki/Regional_Internet_registry 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 [http://en.wikipedia.org/wiki/Unique_local_address 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/ 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.''

[http://www.youtube.com/watch?v=VfOrF5pssCs Presentation on Youtube]

[http://www.qsl.net/k/kb9mwr//wapr/tcpip/DCC2016-IPV6.pdf Abstract]

----
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.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.

<pre>
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</pre>

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
''

----
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 residental connection is a /64 subnet yeilding 18,446,744,073,709,551,616 hosts.

We just need a means of advertising the ham netblocks and automatically configuring filtering. A DNS to register the ham host in, etc

Services

2017-10-08T07:21:11Z

Kb9mwr: updated dns zone files ftp site

{| class="wikitable sortable"
|-
! Maintainer !! Service Name!! URL/IP !! Service Type !! Description !! Other Information
|-
| AMPR ||[[Portal]] || https://portal.ampr.org || HTTPS || manage [[Gateway]], [[Encap.txt]] preferences and ampr.org domain entries (domain entry functionality still under development)|| NONE
|-
| AMPR ||Website || http://www.ampr.org || HTTP || AMPRNet Main Page|| NONE
|-
| AMPR ||Wiki || http://wiki.ampr.org || HTTP || This Wiki|| NONE
|-
| AMPR ||[[44Net mailing list]] || http://hamradio.ucsd.edu/mailman/listinfo/44net || HTTP || mailing list discussion|| NONE
|-
| AMPR ||AMPRNet [[Gateway]] (AMPRGW) || 169.228.34.84 || IP and IPENCAP [[Tunnel]]|| main AMPRNet Router|| Gateways use IP Protocol 4 (IPENCAP) to receive traffic via AMPRGW. Allocation must be registered in the [[Portal]] and gateways must run an AMPRNet routing protocol (i.e. [[RIP]]44 or [[munge script]]).
|-
| AMPR ||[[RIP]]44 || provided via [https://en.wikipedia.org/wiki/Broadcasting_%28networking%29 broadcast] from 44.0.0.1 to all [[gateway]]s registered in the [[portal]] || Routing Information (modified RIPv2 protocol) || distributed by main AMPRNet Router to multicast address 224.0.0.9|| 1.) an enabled IPENCAP tunnel, and 2.) [[ampr-ripd]] or [[rip44d]] must be running and properly configured on your registered gateway
|-
| AMPR ||[[Encap.txt]] || N/A || Routing Information (EMAIL/FTP/HTTP)|| routing information for download|| file must be must be parsed by a self-developed [[munge script]]
|-
| Various Operators||[[Ampr.org]] DNS and Reverse DNS (44.in-addr.arpa) ||
(These hosts maintain a copy of AMPR.ORG and the 44.IN-ADDR.ARPA DNS Zones:)
 ampr.org 
ns2.threshinc.com 
munnari.OZ.AU 
a.coreservers.uk 
ampr-dns.in-berlin.de 
(These hosts maintain a copy of AMPR.ORG and the 44.in-addr.arpa DNS Zones. 44/8 hosts may use as recursive/Client DNS servers:) 
gw.ct.ampr.org (44.88.0.1) 
dns-mdc.ampr.org (44.60.44.3) 
n1uro.ampr.org (44.88.0.9)
|| DNS || name resolution services|| zone files can be downloaded from ftp://gw.ampr.org/pub/
|-
| Various Operators||Network Tools||
http://whatismyip.ampr.org 
http://yo2tm.ampr.org/nettools.php 
http://kb3vwg-010.ampr.org/tools 
http://speedtest.ampr.org 
http://n1uro.ampr.org/do.shtml 
|| HTTP|| source IP checker, speed test, Ping, Traceroute, etc.|| NONE
|-
| Various Operators ||Network Time Protocol Server || kb3vwg-001.ampr.org (Stratum 2) gw-44-137.pi9noz.ampr.org (Stratum 2) f4gve.ampr.org (Stratum 3) || NTP|| Stratum 2 Network Time Server - References US, Canadian and Mexican Stratum 1 Servers|| AMPRNet hosts have OPEN ACCESS to these time servers
|-
| OH7LZB ||[[AMPRNet_VPN]] || http://wiki.ampr.org/index.php/AMPRNet_VPN || VPN|| [http://en.wikipedia.org/wiki/OpenVPN OpenVPN]-based || You must have a X.509 certificate issued by [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]. ARRL membership is not required.
|-
| N1URO ||AMPRNet/RF faxing || http://wiki.ampr.org/wiki/axMail-FAX || Facsimile || Online IP based Facsimile service. You have the ability to send emergency communications from packet via Fax. || [http://axmail.sourceforge.net axMail-FAX] Sofware is here.
|-
| OH1KK || KiwiSDR Kaustinen || http://44.139.48.2 || SDR-receiver || KiwiSDR receiver located at Kaustinen, Finland · 0-30 MHz · Antenna switch extension · Northern Europe || Experimental. Also available on non-amprnet at address http://sdr.vy.fi
|-
|-}

Ipv6

2017-10-08T02:53:51Z

Kb9mwr:

Ipv6

2017-10-08T02:52:38Z

Kb9mwr:

'''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 [http://www.qsl.net/k/kb9mwr//wapr/tcpip/Take_the_Next_Step_with_the_Next_Generation_Protocol.pdf 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 [http://www.wm7rc.org/ 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/ 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 [http://en.wikipedia.org/wiki/Regional_Internet_registry 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 [http://en.wikipedia.org/wiki/Unique_local_address 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/ 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.''

[http://www.youtube.com/watch?v=VfOrF5pssCs Presentation on Youtube]

[http://www.qsl.net/k/kb9mwr//wapr/tcpip/DCC2016-IPV6.pdf Abstract]

----
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.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.

<pre>
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</pre>

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
''

Ipv6

2017-10-08T02:51:24Z

Kb9mwr:

'''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 [http://www.qsl.net/k/kb9mwr//wapr/tcpip/Take_the_Next_Step_with_the_Next_Generation_Protocol.pdf 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 [http://www.wm7rc.org/ 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/ 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 [http://en.wikipedia.org/wiki/Unique_local_address 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/ 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.''

[http://www.youtube.com/watch?v=VfOrF5pssCs Presentation on Youtube]

[http://www.qsl.net/k/kb9mwr//wapr/tcpip/DCC2016-IPV6.pdf Abstract]

----
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.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.

<pre>
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</pre>

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
''

Ipv6

2017-10-08T01:07:36Z

Kb9mwr: start of ipv6 info

'''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 [http://www.qsl.net/k/kb9mwr//wapr/tcpip/Take_the_Next_Step_with_the_Next_Generation_Protocol.pdf 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 [http://www.wm7rc.org/ 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/ 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/ 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.''

[http://www.youtube.com/watch?v=VfOrF5pssCs Presentation on Youtube]

[http://www.qsl.net/k/kb9mwr//wapr/tcpip/DCC2016-IPV6.pdf Abstract]

----
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.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.

<pre>
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</pre>

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
''

FAQ

2017-09-21T18:07:11Z

Kb9mwr: more mailing list url changes

'''Frequently Asked Questions'''

'''What is AMPRNET?'''

AMPRNET stands for Amateur Radio Packet Radio Network. It is a collection of amateur radio-oriented computers, connected together via a variety of technologies, including radio, Internet, and ethernet. However, all of these computers have an IP address that begins with 44 (that is, IP addresses of the form 44.x.x.x). For this reason, AMPRnet can also be referred to as 44-net.
Some further details can be found at https://en.wikipedia.org/wiki/AMPRNet and http://wiki.ampr.org/wiki/Main_Page

'''What is AMPRNET for?'''

The purpose of AMPRNET is to permit experimentation by amateurs in digital networking, and to provide computer services to other amateurs using AMPRNET.

'''What does it cost to use AMPRNET?'''

There is no cost for using any AMPRNET facilities, however there may be costs associated with Internet access to reach AMPRNET and/or amateur radio equipment costs.

'''How do I connect to AMPRNET?'''

There are four main methods people use:

a) IP Tunneling

b) VPN

c) BGP routing

d) Direct radio links.

Note: Functionally, a VPN and a tunnel do much the same thing, except a VPN is designed for privacy (i.e. strong authentication and encryption), while a tunnel is for the transfer of packets, not necessarily encrypted. However, in the AMPRNET world, they tend to get used quite separately and so are discussed separately in this FAQ.

'''What is IP Tunneling?'''

The information that traverses the Internet does so as "packets" of data, traveling over a variety of routes, between a source and a destination. Each packet contains a header, which tells all the devices along the route information such as the source and destination, plus the payload, which is the data to actually be transferred. Clearly, there must be a path all the way from the sources to the destination, and back.
AMPRNET consists of small, non-connected groups of computers, that would otherwise not be able to connect to one another. However, since internet devices along the route really don't care about the contents of the payload section, you can put a complete new packet into that section, including an entirely different header, and it's own payload section. That second header has source and destination addresses completely different to the first header - all that is required is that the first destination recognises the encapsulated packet, de-encapsulates it, and forwards it the the second header destination. Return traffic follows a corresponding process. In that way, 44-net hosts can communicate with other 44-net hosts, by means of encapsulating their data packets in packets to non-44net hosts. This is called tunneling (or encapsulating). A later section in this FAQ discusses installing a tunnel. This diagram http://ericleahy.com/wp-content/uploads/2011/08/IP-Tunnel-Encp-300x256.jpg shows tunnelling another way.
Tunneling is probably the most commonly used method of accessing AMPRNET.

'''What is a VPN?'''

VPN stands for Virtual Private Network. It is a facility that enables a computer to act (using the Internet) as though is is physically connected to another computer network. There are many different ways to set up a VPN, so this is beyond the scope of this FAQ. However it always involves configuring software and accounts on a computer, to connect to the VPN server. Some amateurs who have connections to AMPRNET have set up VPN servers, so that other amateurs can achieve a "virtual" connection to AMPRNET. The technical details, account details and IP address details must be obtained from the operator of that VPN. One such VPN is listed at http://wiki.ampr.org/wiki/AMPRNet_VPN.

'''What is BGP Routing?'''

The Internet has millions of different computers connected to it, each having an address. Devices called routers deliver traffic between computers, and can send "advertisements" to other routers to tell those other routers about the locations of some of those addresses. The protocol used is called BGP, Border Gateway Protocol. If you are fortunate enough to have a computer that can send BGP advertisements, then you can advertise that your computer is part of the AMPRNET address range, and hence receive AMPRNET traffic.

Unfortunately, most most companies and most commercial ISP's will not permit their users to originate BGP advertisements (especially for address ranges that are not in their usual address range), so BGP is not a viable means to connect to AMPRNET for most people.

Installing BGP is beyond the scope of this FAQ. Note however that you must have written permission from Brian Kantor, the administrator of the 44 address space, before you BGP advertise any part of that space.

'''What about radio links?'''

In many places, groups of amateurs have established networks of radio links, and often have used one of the preceding approaches so that those radio networks connect to and become part of AMPRNET. You would need to contact those groups regarding frequencies, modes, and address allocations.

'''Do I need to consider security?'''

Yes! Any computer connected to the Internet must be configured and maintained in a secure fashion, and this includes any computer connected to AMPRNET (regardless of the connection technique). Repeat - you MUST secure your computer! This includes using firewalls, keeping software up to date, using strong passwords, etc etc. In some cases, encryption may also be used.

How to maintain security is beyond the scope of this FAQ. Searching for "How to secure my computer" will return many, many hits though!

'''How do I get an address allocation?'''

If you connect to an existing VPN or existing radio network, it is likely that the operators of those facilities will already have address ranges established and will allocate your address(es). If you wish to establish a new tunnel or BGP-based link, then the process is handled by a semi-automated process on our portal. The steps are:
1. Register using your callsign on the portal https://portal.ampr.org
2. Log in and navigate to the Networks page.
3. Click on your country. A list of regions/subnets may appear; if so, click on the appropriate one.
4. Click on the subnet and you'll be presented with a simple form to complete.
5. If you are requesting a single address for a host, leave the netmask as /32;
6. if you are requesting a block/subnet, select the appropriate netwidth. E.g. for a 256 host subnet, select /24.
7. Put a short message explaining your request in the Message area of the form. Be sure to indicate
if you are planning to directly route a subnet as these require special handling
8. Click Send. Your request will be forwarded to the coordinator for your region/subnet. You'll
receive a confirming email. The coordinator may contact you for further details if required.

'''Can I have a domain name entry for my AMPRNET host?'''

Yes. Currently domain name requests are handled by the area coordinators - contact details are on the portal. Note: the old email robot facility no longer functions.

'''What about IPv6?'''

There is no IPv6 equivalent of AMPRNET at present.

'''How do I configure a Tunnel?'''

The technique varies according to the Operating System you use. However, all involve the creation of a new "pseudo" interface - unlike your normal ethernet network connection, this one doesn't actually exist on the back panel of your computer. However, it exists as far as the Operating System is concerned. A normal ethernet device accepts a data packet (consisting of a header and payload, as previously discussed) and sends it out the ethernet cable (often via a modem, to the Internet). A "pseudo" interface however accepts a data packet, encapsulates it in the data portion of a new packet, adds a new and different header, and passes all that to the ethernet device, which then processes this new data packet as normal, sending it to a recipient who will de-encapsulate it. Reception of tunneled traffic is the reverse process.

Consequently, two requirements apply:

a) The computer must have full connectivity to the non-44 hosts that will send or receive the tunneled packets containing 44-net traffic. You cannot route ALL traffic to the pseudo interface!

b) The pseudo driver must have a mechanism to tell it which non-44 net hosts can handle particular subsets of 44-net traffic - very few can handle the entire 44-net range! It should be noted that the information changes quite frequently, as tunnel hosts come and go, so must be updated as described below.

http://wiki.ampr.org/wiki/Main_Page has links to several different ways of configuring tunnels.

'''How do I obtain and maintain a list of tunnel hosts?'''

There are three main mechanisms:

a) log on to the portal (as described above) and navigate to the "Gateways/List" section that permits downloading of the "encap" file. Download that file, and use a script on the computer to turn it into commands that update the configuration of the tunnel device.

b) receive the encap file by mail, and use a script to process it. You can register for this email on the portal "Gateways/Options" page.

c) Receive and process "broadcasts" of configuration data that are available. This information is broadcast to all gateways listed on the portal. There is a software package called "ampr-ripd" that enables this process

'''Can I just route all 44net traffic via a single tunnel?'''

No. The main AMPRNET gateway does not provide this functionality - you must have a tunnel to each system you wish to contact.

'''What is the AmprGW?'''

The AmprGW is a server run by Brian Kantor at UCSD as part of a long-running Internet research project. It has a number of functions:

a) It provides a selective gateway between non-AMPRNet internet devices and the IPIP (mesh) AMPRNet. For this traffic, it filters at the per-host(/32) level. Each host which is to receive traffic from the Internet into AMPRNet must individually be listed in the permissions file, which is built from the AMPR.ORG DNS 'A' records. If there is no DNS A record for a tunneled amprnet destination host, the traffic is not forwarded in either direction. Therefore, if you want hosts on your subnet to be able to communicate with the Internet, you will need to have your local coordinator add them to the AMPR.ORG DNS for you.

b) It forwards traffic between Internet hosts (including those AMPRNet that are directly connected to the Internet [BGP-routed]) and IPIP tunneled AMPRNet hosts. Some "validity" filtering is applied during this process - traffic which is invalid or mis-configured will be dropped. Note: AmprGW does NOT forward between different IPIP tunneled AMPRNet hosts. That is why you cannot have just a single IPIP tunnel for all of AMPRNet. Thus the tunneled AMPRNet as a whole forms a fully-connected mesh, not a 'star' configuration.

c) AmprGW originates RIP44 broadcasts containing routing information about gateways and the AMPRNet subnets they service. The RIP44 transmissions are sent as IPIP encapsulated UDP packets for port 520 from 169.228.34.84 and sent individually to the commercial (external) address of every gateway. The packets have an inner source address of 44.0.0.1 and an inner destination of 224.0.0.9, the RIP multicast address. They are IPIP encapsulated packets, so without de-encapsulating them, the RIP is not visible to conventional routing software. Specialized software such as 'ampr-ripd' may be employed to make use of the RIP44 broadcasts, to set up AMPRNET routes.

'''Can BGP, VPN and IP tunnel hosts inter-communicate?'''

Yes. The AMPRNET gateway has been configured to support this functionality.

'''Can I put my tunnel on my home LAN and use NAT?'''

Yes. However, in general, a home modem using NAT won't be able to correctly process inbound tunneled 44-net traffic and forward it to the correct host - the "port forward" facility in most NAT devices relies on a port number, but there are no port numbers for a tunnel packet! However, most modems have a "DMZ" facility, whereby all unrecognised traffic (and this includes tunneled traffic) can be forwarded to one particular host on the LAN. That host can then be configured to recognise and correctly process tunneled data. However - security alert! - it will also be exposed to all sorts of other, unwanted traffic as well! See the Security section above.

'''Can I use an AMPRNET VPN on my home LAN?'''

Generally, yes. Most home modem/routers have good support for VPN usage.

'''How can I get help with AMPRNET issues?'''

Many amateurs are willing to assist other hams. There is also a very active mailing list - see http://mailman.ampr.org/mailman/listinfo/44net. The wiki at http://wiki.ampr.org/ has a great deal of information.

'''What about 44.128.0.0/16?'''

Subnet 44.128.0.0/16 is currently reserved for testing. No operational subnets are planned for this address space. Older documentation incorrectly referred to this block of addresses as "private", that is, unrouted like the 192.168.0.0/16 RFC1918 subnet. This is incorrect; the 44.128.0.0/16 subnet can be routed. Do not use it except for brief test purposes.

'''Credits'''

This FAQ originally commenced by Steve VK5ASF, using material from earlier FAQ's, from various contributors to the 44net mailing list, and from Brian Kantor.

Startampr

2017-09-21T18:00:51Z

Kb9mwr: /* Links */

'''startampr''' is a custom suite of [https://en.wikipedia.org/wiki/Bash_%28Unix_shell%29 Bourne Again Shell] scripts developed by KB3VWG and others in the [[44Net mailing list]] Community, that turns a Debian/Ubuntu-based Linux machine into an AMPR [[Gateway]] on boot; and starts an [https://en.wikipedia.org/wiki/IP_in_IP IPENCAP] (or [https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers IP Protocol] number four) tunnel. The primary advantage to using this suite is that it executes and enables AMPR RIP44 daemons, munge scripts, interfaces and routing commands in proper boot order; and references them using the command syntax, default command arguments and practices that have become the de facto standard on [[AMPRNet]]. It is also minimally invasive, in that the machine otherwise remains an "untouched" default installation; and can be returned to an OEM Ubuntu installation by simply removing all associated files and uninstalling all packages added when configuring the machine to run '''startampr''' (please assist me in developing an uninstall script, if interested). Also, if you install a server GUI (e.g. [http://www.webmin.com Webmin]), you can disable the routing features of the machine simply by checking a box, and hitting APPLY (on next reboot, it is disabled). '''The current versions are 1.0 (no longer developed), and 2.0, released to the [[44Net mailing list]] Community on May 26, 2017 at 14:14 UTC.

== Detailed Summary ==

In addition to the first and main script, '''startampr''', other tools included with the official release are: init scripts to execute the file, save the routing table (if using a method that does not automatically save it); and an executable script generator (made using [http://linux.die.net/man/1/sed the sed command]) that can restore the AMPR routing table (i.e. in the case the administrator flushes the table). The script uses the [http://www.linuxfoundation.org/collaborate/workgroups/networking/tunneling ipip Linux Kernel module] and implements [http://linux.die.net/man/8/ip Linux ip] routing table's [https://en.wikipedia.org/wiki/Policy-based_routing policy-based routing] to properly move traffic across the routing plane. It is suggested that [https://en.wikipedia.org/wiki/Iptables iptables] be used to firewall traffic after verification of a proper installation.

The official release uses [[rip44d]] as its [[RIP]]44 protocol daemon; but [[ampr-ripd]] or [[Encap.txt]] with a [[munge script]] may be used (instructions by KB9MWR use ampr-ripd). '''To operate a [[Gateway]] on [[AMPRNet]], you must have a method of obtaining up-to-date route information. On AMPRNet, a variant of [https://en.wikipedia.org/wiki/Routing_Information_Protocol RIP version 2] protocol, named [[RIP]]44 is used. [https://en.wikipedia.org/wiki/Routing_Information_Protocol RIP version 2] is not the same as [[RIP]]44.''' rip44d is written in the Perl programming language by Heikki Hannikainen, OH7LZB. [[ampr-ripd]] is written in C by YO2LOJ. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical. The developer choose rip44d simply because it was the only daemon available when version 1.0 was developed. The use of any method to add route information to table 44 will work. It should be noted that: '''startampr''' was developed around '''rip44d'''; and improves on features not included (e.g. reload of routing table upon reboot). The scripts to backup/restore are not needed when using [[ampr-ripd]] (but can be developed to provide geographically-local tertiary sources of the AMPR routing table).

'''NOTE: if you do not wish to compile software, you must use [[rip44d]] or [[Encap.txt]] with a [[munge script]].'''

== 2.0 Security Update ==

'''startampr 2.0's code includes a security fix that corrects a routing issue that allows unencapsulated traffic from the tunnel to leak onto the LAN or Public Internet interface in version 1.0 - this only occurs when a AMPRNnet-facing user attempts to connect using invalid source IPs or invalid AMPRNet IP address'''. In original development of version 1.0, it was considered that this behavior could be valid to reach subnets ran by operators using the option at: [[Announcing your allocation directly]]; '''but do not make their tunnel available on a non-44.0.0.0/8 address''' (it was announced on the [[44Net mailing list]] on 04AUG2015, that AMPRGW now routes traffic to/from BGPed and IPENCAPed AMPR subnets, making this programmatic workaround unnecessary).

It is a generally accepted practice on the Internet that network operators source filter their traffic, making BGPed subnets an exception for AMPRNet Gateways (see [https://tools.ietf.org/html/rfc3013 RFC3013, section 4.3 and 4.4]). It is also accepted AMPRNet practice that these operators consider running a tunneled Gateway on any non-AMPRNet IP available for accessibility to/from those running IPENCAP Gateways. It may be useful to also have redundant VLANs on two or more interfaces possessing the same Public IP at two or more borders; and run a script between the AMPR Gateways - using [https://en.wikipedia.org/wiki/Dynamic_DNS Dynamic DNS] to synchronize them, verify if connectivity goes down on either device's tunl0 interface and update the [[Portal]] accordingly.

I'm happy and willing to work with any BGP subnet operator who wishes to develop a script to establish an AMPR Gateway for your multi-homed AMPRNet BGPed subnet.

= Requirements, Installation Overview and Features =

# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is known as an AMPRnet Gateway; and will receive RIP44 updates from the main [[Gateway]]. It will take some time before Amprgw will learn about new gateways.
# The instructions below are currently only for Debian/Ubuntu, but there's nothing Debian-specific - it should work fine on other distributions (if the correct packages used (e.g. wget/curl, The Bourne Again Shell/BASH, sed, ip, chmod, PERL, etc.) Interface names, file and folder locations, file permissions, etc. are edited.

You must first properly install:
* the operating system and network interfaces
* then properly install '''startampr''' at '''/usr/local/sbin''' to enable the tunnel. '''The tunnel interface must be operational and in 'UP' status before proceeding.'''
* the [[RIP]]44 daemon ([[rip44d]] uses the location '''/usrlocal/sbin/''') which receives periodic routing table updates from the [[AMPRNet]] routing service, and inserts them in the Linux routing table of your choice (most users use table 44; and the scripts use this value as well). '''You must verify that you are receiving route information before proceeding.'''
* boot script for '''startampr''', to '''/etc/init/'''
* (Optional) a script to backup the routing table and create a corresponding restore script, at '''/etc/cron.hourly/'''
* (Optional) a script to restore the AMPRNet routing table on boot, at '''/etc/if-ip.d/'''

= Installation of startampr =

Install the the script to '''/usr/local/sbin''' and '''sudo chmod ug+x /usr/local/sbin/startampr'''

After obtaining the correct password from the route announcement and entering it into the properly configured script, install the boot and interface-up scripts (sample init scripts provided).

The additional script '''/etc/cron.hourly/backup_ampr''' creates an hourly backup of the AMPR routing table, located in two files at '''/usr/local/sbin''':

* '''/usr/local/sbin/table44_bak ''' - It is a text file that contains a copy of output from the command: 'ip route get table 44'
* '''/usr/local/sbin/restore44sh''' - It contains a copy of '''table44_bak''' with the command "ip route add table 44 " appended to each line. '''backup_ampr''' gives this file executable permissions to user:root and group:root. Execute this file using the command: '''sudo ./usr/local/sbin/restore44sh''' to restore your routing table if the need ever occurs.

You can verify the backup is running by issuing the command: '''ls -l /usr/local/sbin/restore44sh''' and '''ls -l /usr/local/sbin/table44_bak'''
If the machine has been up, the files should be no more than an hour old.

That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The additional scripts provided store the current routing table in a local file hourly and load it from there when starting up. Thereafter, after every hour of uptime your routing table is backed up at :17 on the hour. This backup can be used if you ever need to execute the ip command to flush table 44.

= Installation of dependencies on Debian/Ubuntu =

'''If you use rip44d''', install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets

sudo apt-get install perl libio-socket-multicast-perl libio-interface-perl

recommended:

sudo apt-get install traceroute openssh-server ipset

= Installation of dependencies on other distributions =

Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.

= Script =

#!/bin/bash
#############################################################
###STARTAMPR v2.0 May 26, 2017###
###
### TO DO - Have the AMPRNet Community test and verify
###
### CHANGELOG
###
### v2.0 RC4
### - Dialogue about how to add routes and rules for any created test subnet(s).
###
### v2.0 RC3
### - Exclusively seperates route and tables, as well as priotities by: class and type
### - This makes unnecessary the exclusion of local subnets in ampr-ripd using the '-a' switch,
### by adding local 44 network(s) to a higher priority routing table
### - This should enable you can to become a tunnel GW for BGPed 44/8 subnets
### - Provides table 7777 as a BLACKHOLE/NULL Route
### - Adds script to load last hourly backup of table 44 on boot
### - With script backup_ampr, creates a backup of the routing table a file named table44_bak
### and an executable restore44sh hourly to use on the running machine to
### restore table 44 if the table needs to be flushed during uptime
###
### v2.0
### - Streamlined commands and routes
### - Placed syntax for Debian/Ubuntu and OpenWRT/LEDE devices
#############################################################
## This script was developed by KB3VWG on a standard
## Ubuntu 16.04.2 LTS PC eth0 configured to the Public facing
## LAN and eth1 to the 44LAN. It is designed to enable an
## AMPR Router using the ampr-ripd v2.0, the standard ampr-ripd,
## using the -t switch to add routes to routing table '44'
## with no further configuration needed (firewall optional)
##############################################################
##################################################################
## This script was modified by LX1DUC to automate even more tasks.
##################################################################
##################################################################
## Thanks to PE1CHL for discovering the need for policy-based routing
## Thanks to KI4SZJ for testing v2.0
##################################################################

### ENABLE IP FORWARDING ###
sysctl -w net.ipv4.ip_forward=1
## Allows traceroute to respond using 44net IP of tunl0 or br-amprlan ##
echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr

################### AMPRNet IPENCAP UBUNTU SYNTAX #######################
# modprobe ipip
# ip tunnel add tunl0 mode ipip
###NUMBER tunl0 with a /32 from your allocation
###(you may reuse this IP on an Ethernet interface
# ip addr add <IP from your 44>/32 dev tunl0
# ip link set tunl0 mtu 1480 up
# ip tunnel change tunl0 ttl 64 tos inherit pmtudisc

################### AMPRNet IPENCAP OpenWRT/LEDE SYNTAX #######################
# ip tunnel add tunl0
# ip tunnel change tunl0 mode ipip ttl 64 tos inherit pmtudisc
###(you may reuse this IP on an Ethernet interface
# ip addr add <IP from your 44>/32 dev tunl0
# ip link set tunl0 mtu 1480 up

################### OPTIONAL - DEFAULT ROUTE FOR INTERNET ACCESS #######################
ip route add default dev tunl0 via <AMPRGW_IP> onlink proto 44 table 44

################### POLICY-BADED ROUTING #######################
###OPTIONAL LOCAL RULES
ip rule add from <CIDR_44_allocation> to <LAN e.g. 192.168.1.0/24> table main priority 22

#REQUIRED RULES
ip rule add to <CIDR_44_allocation> table main priority 44
ip rule add dev tunl0 table 44 priority 45
ip rule add dev <interface_for_44LAN> table 44 priority 46
ip rule add from <CIDR_44_allocation> table 44 priority 47

###SOME OF THIS MAY BE NEEDED TO RUN ampr-ripd from another folder than the compile option
###make sure you create the correct save and working folders, etc if you cant recompile ampr-ripd
# This directory is not persistent on OpenWRT/LEDE, it must be made on boot for dynamic filtering
# mkdir /var/lib/ampr-ripd
# Create a blank bootstrap file at /etc/config/encap.txt for this to work
# ln -s /etc/config/encap.txt /tmp/lib/ampr-ripd/encap.txt
# cd /usr/local/sbin

################### RUN AMPR-RIPD
################### WITH DYNAMIC FIREWALL SCRIPT USING -x
################### see http://wiki.ampr.org/wiki/Firewalls for dynamic script
./ampr-ripd-2.0.x64_Ubuntu16 -i <tunl_interface> -t 44 -a <CIDR_44_allocation> -s -x '/etc/config/load_ipipfilter.sh' -L <CALLSIGN>@<GRID_SQUARE> &

= Notes =

* '''startampr documentation uses tunl0 as the tunnel interface (it is the default on RIP44 daemons) and table 44 for those routes. Use the -i <if> and -t <ip table> option to change to another. The command arguments differ between [[rip44d]] and [[ampr-ripd]]. startampr uses rip44d. See the documentation for the RIP44 programs if decide to use custom interfaces, tables or switch to a routing daemon other than [[rip44d]].'''
* '''The script places the routing daemon at /usr/local/sbin/rip44d_<version number> (this assists in preventing inadvertent running of RIP44 Protocol before you have configured startampr.
* '''The routing rules do not account for rogue traffic containing both an invalid source and destination IP (which the security of the [[Portal]] generally prevents). Use iptables to DROP forwarding of all traffic entering tunl0 not matching a source or destination of in your allocated subnet(s). This can be done by adding adding rules to drop forwarding, by default, packets not possessing correct source and destination IPs in the range of 44.0.0.0/8, etc.'''
* The -a <IP in [[Portal]]> is used to remove your routes from the table (which is incorrect, as they are local). '''startampr''' places your local routes in a higher routing table, eliminating the need to use the -a argument. This is a good feature for those who are assigned a dynamic IP address from their Internet Service Provider.
* The tunnel interface must be up and configured before '''rip44d''' starts up. '''startampr''' places this command in the proper location.
* rip44d automatically adds an AMPR route to the Main AMPRNet Gateway on table 44
* The '''startampr''' backup script '''/etc/cron.hourly/backup_ampr''' is added to a folder that is configured in Ubuntu, by default, to run scripts at :17 after the hour. The Main AMPR Gateway sends an update every five minutes. For advanced instructions on changing this time interval, see [https://help.ubuntu.com/community/CronHowto the Ubuntu Community cron HowTo].
* A strict assortment of: file permissions, naming conventions and leading characters (e.g. '''"#!/bin/bash"''') are required in '''/etc/init/''', '''/etc/if-up.d/''' (used in a script to reload table 44 on boot) and '''/etc/cron.hourly/'''. Note that: '''startampr''' has properly named those files. If you wish to edit them, please follow the documentation and README for more details.
* '''Please note that: any machine acting as an AMPRNet Gateway must explicitly create high-priority routing rules for all traffic addressed to or from eth0. The network assigned to eth0 must be configured to ONLY use table main.''' No other valid configuration has been found to properly work (discovered by PE1CHL and tested by KB3VWG and others in the [[44Net mailing list]] Community). '''This is due to the unique fact that, on AMPRNet routers, 44.0.0.0/8 exists on both the Public (eth0) and AMPRNet-facing (tunl0) sides of the device. There is no way to properly differentiate the route or destination interface of the traffic received from 44.0.0.0/8 over tunl0 (with your 44Router's 44 IP address), versus that from eth0 (on the Gateway's Public-facing IP). Meaning, there is no way to route traffic for all cases, except by SOURCE OR DESTINATION IP ADDRESS. Therefore, ALL traffic to and from the network facing eth0, must use eth0.''' In order to access your AMPRNet from a local network, you must create another routable LAN (and add TO rules, e.g. ip route add to 172.55.0.0/24 table main priority - and masquerade accordingly if configured to reach all of 44.0.0.0/8), or simply connect directly to an AMPR-facing interface. The rule to only use the main table for the eth0 network allows the AMPRNet Gateway to reach 44 hosts on the Public Internet, leaving the operator to provide all routing rules for AMPR-facing interfaces, which is the intent of '''startampr'''.

= Support, bug reports and improvements =

If you have questions to ask about the usage of this script, please contact the [[44Net mailing list]].

If you have improvements to the script and wish to submit a patch, please contact KB3VWG on the [[44Net mailing list]], or via contact details in the [[Portal]]. Thank you!

The daemon was written by Lynwood, KB3VWG, and with major contributions from PE1CHL (for implementation of policy-based IP routing), Heikki Hannikainen, OH7LZB (to version 1.0's integration with '''[[rip44d]]'''), and Marc, LX1DUC (to automate enabling of IP forwarding).

=See also=

* [[Ubuntu Linux Gateway Example]]
* [[Setting up a gateway on Linux]]
* [[ampr-ripd]]
* [[Encap.txt]]
* [[munge script]]
* [[rip44d]]

= Links =

* [http://www.qsl.net/kb9mwr/wapr/tcpip/ampr-ripd.html Alternative installation instructions by KB9MWR]
* [http://marc.storck.lu/blog/2013/08/howto-setup-an-amprnet-gateway-on-linux/ Alternative installation instructions by Marc, LX1DUC]
* [(link to KB3VWG's site here) Detailed Readme and Installation instructions by KB3VWG]

Archive/Main Page

2017-09-21T17:55:25Z

Kb9mwr:

Welcome to the AMPRNet Wiki.

Since its allocation to Amateur Radio in the mid-1980's, Internet network 44 (44.0.0.0/8), known as the AMPRNet™, has been used by amateur radio operators to conduct scientific research and to experiment with digital communications over radio with a goal of advancing the state of the art of Amateur Radio networking, and to educate amateur radio operators in these techniques. - [http://www.ampr.org/ www.ampr.org]

__NOTOC__
== Starting points ==
* [[Quickstart]] guide for getting onto the [[AMPRNet]]
* Basic information about the [[AMPRNet]] and the [[ampr.org]] domain
* [[Services]] available on AMPRNet
* If you are looking to get an IP allocation within the 44/8 AMPRNet please read the [[Portal]] page.
* Frequently Asked Questions (FAQ) [[FAQ]]

== How to connect to AMPRNet ==

* Instructions for [[Setting up a gateway on Linux|setting up a Linux gateway]]
* Instructions for [[Setting up a gateway on OpenBSD|setting up an OpenBSD gateway]]
* Instructions for [[setting up a gateway on Cisco Routers|setting up a gateway on Cisco Routers]].
* Instructions for [[setting up a gateway on MikroTik Routers|setting up a gateway on MikroTik Routers]].
* Instructions for [[setting up a gateway on OpenWRT|setting up a gateway on OpenWRT]].
* Instructions for [[setting up a gateway on Ubiquiti EdgeRouter|setting up a gateway on Ubiquiti EdgeRouter]].
* Instructions for [[setting up a gateway on a VyOS instance|setting up a gateway on a VyOS instance]].
* Instructions for [[announcing your allocation directly|directly announcing your allocation via your Internet Service Provider (ISP)]].
* Instructions for [[AMPRNet VPN|Accessing AMPRNet via VPN]] (experimental).
* [[Why can't I just route my AMPRNet allocation directly myself ?]]
* If you already operate a [[gateway]] please ensure you have registered on the [[portal]] and "claimed" your [[gateway]].

== Mailing List ==
To keep up-to-date on AMPRNet information please consider joining the [[44Net mailing list]].

== Contribute! ==
If you wish to contribute to the wiki, please send an email to <tt>wiki (at) ampr.org</tt> introducing yourself. Please specify your full name, amateur radio callsign and your preferred username. A login will then be created for you.

== Terms of Service ==
Use of 44.0.0.0/8 address space is governed by these [http://www.ampr.org/terms-of-service/ Terms of Service]

== All Pages ==
[http://wiki.ampr.org/wiki/Special:AllPages Here's a list of all pages currently on the AMPRNet Wiki]

44Net mailing list

2017-09-21T17:54:58Z

Kb9mwr:

The [http://mailman.ampr.org/mailman/listinfo/44net AMPRNet working group discussion list] is a mailing list where amprnet users and gateway operators discuss all things [[AMPRNet]]. Subscribe and browse the archives to learn more!

* [http://mailman.ampr.org/mailman/listinfo/44net http://mailman.ampr.org/mailman/listinfo/44net]

44Net mailing list

2017-09-21T17:54:31Z

Kb9mwr:

Rip44d

2017-07-05T19:59:59Z

Kb9mwr: /* Links */

Technically, rip44d is a custom RIPv2 daemon which receives periodic routing table updates from the [[AMPRNet]] routing service, and inserts them in the Linux routing table.

RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] [[Gateway]], it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).

The RIP protocol is used in a slightly unconventional way on the AMPRNet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.

rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.

= Requirements =

# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.
# The instructions below are currently only for Debian/Ubuntu, but there's nothing Debian-specific in rip44d - it should work fine on other distributions. It does not read or touch any of the operating system's configuration files.

= Installation of dependencies on Debian/Ubuntu =

install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets

sudo apt-get install perl libio-socket-multicast-perl libio-interface-perl

install something to download the daemon, if needed

sudo apt-get install curl

= Installation of dependencies on other distributions =

Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.

If all else fails, but you have Perl installed already, you can use CPAN to install the module. For details, please see the [http://www.cpan.org/modules/INSTALL.html CPAN installation guide].

cpan App::cpanminus
cpanm IO::Socket::Multicast

= Installation of rip44d =

Download the daemon

curl -O https://raw.github.com/hessu/rip44d/master/rip44d

Make it executable

chmod u+x rip44d

= Run it for the first time =

Run it first with the -v option to verify that it sees the route announcements from amprgw, and to learn the plaintext password used to authenticate the RIP packets (it's not included in the script, and I'm not posting it here, so that spoofing can only be done by those who are already receiving the announcements). Wait up to 5 minutes until the routes are transmitted, and it'll complain about the password it's not expecting:

hessu@gateway:~$ sudo ./rip44d -v
found local address: 1.2.3.4
found local address: 127.0.0.1
found local address: 44.255.259.253
opening UDP socket...
entering main loop, waiting for RIPv2 datagrams
received from 44.0.0.1: 520: 504 bytes
RIPv2 packet contains password PasswordFoundHere but we require none

Run it again with the correct password

hessu@gateway:~$ sudo ./rip44d -p PasswordGoesHere

Within 5 minutes it should receive the new routing table and take it into use. For added fun, use -v (verbose) or -d (debug, really verbose) to see what it does.

After confirming that it works, move it to /usr/local/sbin (or something) and put it in your boot scripts '''(see: [[startampr]])'''. At minimum, the following lines in /etc/rc.local should do the required tricks to bring Amprnet routing up. The IP addresses are intentionally invalid – you'll need to replace them with your own.

# Route my own subnet to blackhole, just to make sure I don't accidentally
# transmit packets destined for us back out to Amprgw and create a loop.
# More specific routes will route packets for these addresses out on the
# correct radio interfaces.
/sbin/ip route add blackhole 44.255.259.0/24
# Bring up the tunnel interface and assign an IP address to it.
/sbin/ifconfig tunl0 44.255.259.253 up || exit 2
# Start up the RIP routing daemon to learn the routing table.
/usr/local/sbin/rip44d -p PasswordGoesHere < /dev/null &

That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The daemon should really be improved to store the current routing table in a local file and load it from there when starting up. '''(See: [[startampr]] about configuring reload of the AMPR routing table upon reboot with rip44d.)'''

The above route add command will cause packets destined to 44.255.259.* to be dropped on the floor, unless a more specific route (such as 44.255.259.0/25) exists. If you route the whole /24 subnet to your radio interface, the blackhole route should not be used. If you have smaller subnets or per-host routes for each user host, the blackhole route will prevent packets destined to unused addresses from getting into a loop between your gateway and the Amprgw.

= Notes =

* rip44d automatically ignores announced routes which are pointed to the system's local addresses. The addresses are automatically learned using /sbin/ifconfig, but you can add more gateway addresses using -a (comma-separated list of IP addresses).
* It expects that your tunnels are configured on tunl0. Use the -i <if> option to change to another. The tunnel interface must be up and configured before rip44d starts up.
* Old encap routes may be present, the daemon will overwrite them as necessary (it won't touch more specific routes, or ones which are not found in the route advertisements). You don't need to "clean" the routing table before running rip44d if you have populated it from encap.txt.
* rip44d does not automatically start, see [[startampr]] for more information about running on boot

= Support, bug reports and improvements =

If you have questions to ask about the usage of this daemon, please contact the [[44Net mailing list]].

If you have improved the daemon and wish to submit a patch, please use Github. Create an account, fork the rip44d repository to your own private repository, push your changes there, and submit a merge request. I'll then merge the changes in the master source tree and release a new version. Thank you!

Github repository: [https://github.com/hessu/rip44d https://github.com/hessu/rip44d]

The daemon was written by Heikki Hannikainen, OH7LZB.

Setting up a gateway on Linux

2017-06-26T23:07:43Z

Kb9mwr: /* Example Gateway Configuration Instructions */

There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite.

Before configuring the Linux gateway you'll need to:
# Using the [[Portal]], obtain your AMPRnet 44/8 IP addresses from a regional coordinator.
# Obtain a public static IP address for your gateway.
# Using the [[Portal]], create an entry for your gateway.
# Get some of your 44.* IP addresses registered in the [[ampr.org]] DNS.

= Flavours of Linux gateways =

== Native Linux kernel AX.25 and IPIP tunneling ==

Linux contains the necessary building blocks for a gateway without much added software. Radio interfaces are configured much like any other network interfaces such as Ethernet, they're just given amateur radio callsigns in addition to an IP address (callsign will act the role of the Ethernet MAC address). If you're familiar with Linux configuration but have not heard of NOS, or if you wish to go with minimal amount of moving parts, this would probably be your choice.

Setting up a native Linux gateway consists of two main steps:

=== Step 1: Setting up tunnel routing to the rest of the AMPRnet===
Configuring your Linux system to learn about other AMPRNet [[gateway| gateways]] can be done two ways:

# Automatically learn about other gateways via modified RIPv2 advertisements. Two popular programs to do this are:
## Using [[ampr-ripd]], a C based routing daemon
## Using [[rip44d]], a PERL based routing daemon
# Manually Downloading the [[encap.txt]] file using FTP and setting up routes using a [[munge script]] is the traditional method

====Example Gateway Configuration Instructions====
* [[Ubuntu Linux Gateway Example]]
* [http://www.qsl.net/k/kb9mwr//wapr/tcpip/ampr-ripd.html Two Interface Debian Linux Amprnet Gateway Example]
* [[URONode|N1URO's information on setting up a gateway on Linux]]

=== Step 2: Setting up radio interfaces in Linux===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Linux AX.25 set-up]
* 802.11 WiFi on amateur frequencies (2.4 or 5 GHz) is a new popular way to set up fast links.

== Running JNOS (or other NOS) on top of Linux ==

If you're already familiar with running NOS on top of DOS or Linux, or wish to keep the AMPRnet IP packet routing away from the host Linux system, it might make sense to run JNOS as an application on top of Linux.

The downside is that it'll have a slightly higher overhead (consumed memory and CPU), and you'll have two IP routers running on top of each other instead of just one, which is seen as slightly complicated by some.

The upside is that you'll also get the JNOS BBS-type features, and some other traditional services without installing additional software on top.

John Martin KF8KK has written a [http://kf8kk.com/packet/jnos-linux/linux-jnos-setup-1.htm Linux - Jnos Setup and Configuration HOW-TO].

=See also=

* [[Ubuntu Linux Gateway Example]]
* [[startampr]]

Setting up a gateway on Linux

2017-06-26T23:07:19Z

Kb9mwr: /* Example Gateway Configuration Instructions */

There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite.

Before configuring the Linux gateway you'll need to:
# Using the [[Portal]], obtain your AMPRnet 44/8 IP addresses from a regional coordinator.
# Obtain a public static IP address for your gateway.
# Using the [[Portal]], create an entry for your gateway.
# Get some of your 44.* IP addresses registered in the [[ampr.org]] DNS.

= Flavours of Linux gateways =

== Native Linux kernel AX.25 and IPIP tunneling ==

Linux contains the necessary building blocks for a gateway without much added software. Radio interfaces are configured much like any other network interfaces such as Ethernet, they're just given amateur radio callsigns in addition to an IP address (callsign will act the role of the Ethernet MAC address). If you're familiar with Linux configuration but have not heard of NOS, or if you wish to go with minimal amount of moving parts, this would probably be your choice.

Setting up a native Linux gateway consists of two main steps:

=== Step 1: Setting up tunnel routing to the rest of the AMPRnet===
Configuring your Linux system to learn about other AMPRNet [[gateway| gateways]] can be done two ways:

# Automatically learn about other gateways via modified RIPv2 advertisements. Two popular programs to do this are:
## Using [[ampr-ripd]], a C based routing daemon
## Using [[rip44d]], a PERL based routing daemon
# Manually Downloading the [[encap.txt]] file using FTP and setting up routes using a [[munge script]] is the traditional method

====Example Gateway Configuration Instructions====
* [[Ubuntu Linux Gateway Example]]
* [http://www.qsl.net/k/kb9mwr//wapr/tcpip/ampr-ripd.html Two Interface Debian Linux Amprnet Gateway]
* [[URONode|N1URO's information on setting up a gateway on Linux]]

=== Step 2: Setting up radio interfaces in Linux===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Linux AX.25 set-up]
* 802.11 WiFi on amateur frequencies (2.4 or 5 GHz) is a new popular way to set up fast links.

== Running JNOS (or other NOS) on top of Linux ==

If you're already familiar with running NOS on top of DOS or Linux, or wish to keep the AMPRnet IP packet routing away from the host Linux system, it might make sense to run JNOS as an application on top of Linux.

The downside is that it'll have a slightly higher overhead (consumed memory and CPU), and you'll have two IP routers running on top of each other instead of just one, which is seen as slightly complicated by some.

The upside is that you'll also get the JNOS BBS-type features, and some other traditional services without installing additional software on top.

John Martin KF8KK has written a [http://kf8kk.com/packet/jnos-linux/linux-jnos-setup-1.htm Linux - Jnos Setup and Configuration HOW-TO].

=See also=

* [[Ubuntu Linux Gateway Example]]
* [[startampr]]

Setting up a gateway on Linux

2017-06-26T23:06:17Z

Kb9mwr: /* Example Gateway Configuration Instructions */

There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite.

Before configuring the Linux gateway you'll need to:
# Using the [[Portal]], obtain your AMPRnet 44/8 IP addresses from a regional coordinator.
# Obtain a public static IP address for your gateway.
# Using the [[Portal]], create an entry for your gateway.
# Get some of your 44.* IP addresses registered in the [[ampr.org]] DNS.

= Flavours of Linux gateways =

== Native Linux kernel AX.25 and IPIP tunneling ==

Linux contains the necessary building blocks for a gateway without much added software. Radio interfaces are configured much like any other network interfaces such as Ethernet, they're just given amateur radio callsigns in addition to an IP address (callsign will act the role of the Ethernet MAC address). If you're familiar with Linux configuration but have not heard of NOS, or if you wish to go with minimal amount of moving parts, this would probably be your choice.

Setting up a native Linux gateway consists of two main steps:

=== Step 1: Setting up tunnel routing to the rest of the AMPRnet===
Configuring your Linux system to learn about other AMPRNet [[gateway| gateways]] can be done two ways:

# Automatically learn about other gateways via modified RIPv2 advertisements. Two popular programs to do this are:
## Using [[ampr-ripd]], a C based routing daemon
## Using [[rip44d]], a PERL based routing daemon
# Manually Downloading the [[encap.txt]] file using FTP and setting up routes using a [[munge script]] is the traditional method

====Example Gateway Configuration Instructions====
* [[Ubuntu Linux Gateway Example]]
* [[http://www.qsl.net/k/kb9mwr//wapr/tcpip/ampr-ripd.html Two Interface Debian Linux Amprnet Gateway]]
* [[URONode|N1URO's information on setting up a gateway on Linux]]

=== Step 2: Setting up radio interfaces in Linux===

* [http://www.tldp.org/HOWTO/AX25-HOWTO/ Linux AX.25 set-up]
* 802.11 WiFi on amateur frequencies (2.4 or 5 GHz) is a new popular way to set up fast links.

== Running JNOS (or other NOS) on top of Linux ==

If you're already familiar with running NOS on top of DOS or Linux, or wish to keep the AMPRnet IP packet routing away from the host Linux system, it might make sense to run JNOS as an application on top of Linux.

The downside is that it'll have a slightly higher overhead (consumed memory and CPU), and you'll have two IP routers running on top of each other instead of just one, which is seen as slightly complicated by some.

The upside is that you'll also get the JNOS BBS-type features, and some other traditional services without installing additional software on top.

John Martin KF8KK has written a [http://kf8kk.com/packet/jnos-linux/linux-jnos-setup-1.htm Linux - Jnos Setup and Configuration HOW-TO].

=See also=

* [[Ubuntu Linux Gateway Example]]
* [[startampr]]