Well, that's kind of the point -- not many people in VK have registered their allocations in the portal, and may not even be aware of the portal's existence or purpose. So, the idea would be to contact those who are still actively using addresses, and get them to register their address blocks in the portal. 73, Matt VK2RQ On 13/07/2013, at 1:06 AM, John Hays <john(a)hays.org> wrote:

I suspect this is the direction the new VK coordinator is headed as well. If there are isolated islands out there, then of course they can use any IP addresses they want, but if at some point they decide they want to connect to the wider network, then it is easier if they are sitting on a unique allocation. 73, Matt VK2RQ On 13/07/2013, at 7:18 AM, K7VE - John &lt;k7ve(a)k7ve.org&gt; wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > We are probably going to flush all old 44.24.x.x soon -- > portal.ampr.orgwill be our authoritative source. Australia could > consider doing the same. > If they aren't connected to the rest of the network it really doesn't > matter. > > > ------------------------------ > John D. Hays > K7VE > PO Box 1223, Edmonds, WA 98020-1223 > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> > <http://www.facebook.com/john.d.hays> > > > On Fri, Jul 12, 2013 at 1:46 PM, Matt VK2RQ &lt;matt.vk2rq(a)gmail.com&gt; wrote: > >> (Please trim inclusions from previous messages) >> _______________________________________________ >> Well, that's kind of the point -- not many people in VK have registered >> their allocations in the portal, and may not even be aware of the portal's >> existence or purpose. So, the idea would be to contact those who are still >> actively using addresses, and get them to register their address blocks in >> the portal. >> >> 73, >> Matt VK2RQ >> >> On 13/07/2013, at 1:06 AM, John Hays &lt;john(a)hays.org&gt; wrote: >> >>> Why not use portal.ampr.org >>> >>> On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" < >> vk4fq(a)smellyblackdog.com.au&gt; wrote: >>> >>>> (Please trim inclusions from previous messages) >>>> _______________________________________________ >>>> Guys >>>> I am trying to create a resonable map of ampr ips that are in use in >>>> Australia so when people request they canbe given ranges that are not >> being >>>> used. If you have or no of a range of IP's that are being used >> downunder, >>>> could you please let me know by emailing >> samantha(a)smellyblackdog.com.au >>>> >>>> Regards >>>> >>>> Sam >>>> Amateur Radio Callsign: VK4FQ / VK4TTT >>>> Owner: VK4RCN P25 Repeater Cairns >>>> Sysop: APRS Cairns >>>> Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) >>>> _________________________________________ >>>> 44Net mailing list >>>> 44Net(a)hamradio.ucsd.edu >>>> http://hamradio.ucsd.edu/mailman/listinfo/44net >>>> http://www.ampr.org/donate.html >>> >>> _________________________________________ >>> 44Net mailing list >>> 44Net(a)hamradio.ucsd.edu >>> http://hamradio.ucsd.edu/mailman/listinfo/44net >>> http://www.ampr.org/donate.html >> >> _________________________________________ >> 44Net mailing list >> 44Net(a)hamradio.ucsd.edu >> http://hamradio.ucsd.edu/mailman/listinfo/44net >> http://www.ampr.org/donate.html >

Hi John Before we took such a drastic move, I was asking to see who actually still used the 44net range in the land downunder. Even the encap.txt file is not a reliable source of information Thanks to the VK's who are active and contacted me Sam VK4FQ|VK4AA|VK4TTT ----- Original Message ----- From: "K7VE - John" &lt;k7ve(a)k7ve.org&gt; To: "AMPRNet working group" &lt;44net(a)hamradio.ucsd.edu&gt; Sent: Saturday, July 13, 2013 9:19 AM Subject: Re: [44net] Re Networks in OZ > (Please trim inclusions from previous messages) > _______________________________________________ > Or request a new one :) > > > ------------------------------ > John D. Hays > K7VE > PO Box 1223, Edmonds, WA 98020-1223 > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> > <http://www.facebook.com/john.d.hays> > > > On Fri, Jul 12, 2013 at 3:37 PM, Matt VK2RQ &lt;matt.vk2rq(a)gmail.com&gt; wrote: > >> (Please trim inclusions from previous messages) >> _______________________________________________ >> I suspect this is the direction the new VK coordinator is headed as well. >> If there are isolated islands out there, then of course they can use any >> IP >> addresses they want, but if at some point they decide they want to >> connect >> to the wider network, then it is easier if they are sitting on a unique >> allocation. >> >> 73, Matt VK2RQ >> >> On 13/07/2013, at 7:18 AM, K7VE - John &lt;k7ve(a)k7ve.org&gt; wrote: >> >> > (Please trim inclusions from previous messages) >> > _______________________________________________ >> > We are probably going to flush all old 44.24.x.x soon -- >> > portal.ampr.orgwill be our authoritative source. Australia could >> > consider doing the same. >> > If they aren't connected to the rest of the network it really doesn't >> > matter. >> > >> > >> > ------------------------------ >> > John D. Hays >> > K7VE >> > PO Box 1223, Edmonds, WA 98020-1223 >> > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> >> > <http://www.facebook.com/john.d.hays> >> > >> > >> > On Fri, Jul 12, 2013 at 1:46 PM, Matt VK2RQ &lt;matt.vk2rq(a)gmail.com&gt; >> wrote: >> > >> >> (Please trim inclusions from previous messages) >> >> _______________________________________________ >> >> Well, that's kind of the point -- not many people in VK have >> >> registered >> >> their allocations in the portal, and may not even be aware of the >> portal's >> >> existence or purpose. So, the idea would be to contact those who are >> still >> >> actively using addresses, and get them to register their address >> >> blocks >> in >> >> the portal. >> >> >> >> 73, >> >> Matt VK2RQ >> >> >> >> On 13/07/2013, at 1:06 AM, John Hays &lt;john(a)hays.org&gt; wrote: >> >> >> >>> Why not use portal.ampr.org >> >>> >> >>> On Jul 11, 2013, at 7:15 PM, "VK4FQ/VK4TTT Sam" < >> >> vk4fq(a)smellyblackdog.com.au&gt; wrote: >> >>> >> >>>> (Please trim inclusions from previous messages) >> >>>> _______________________________________________ >> >>>> Guys >> >>>> I am trying to create a resonable map of ampr ips that are in use in >> >>>> Australia so when people request they canbe given ranges that are >> >>>> not >> >> being >> >>>> used. If you have or no of a range of IP's that are being used >> >> downunder, >> >>>> could you please let me know by emailing >> >> samantha(a)smellyblackdog.com.au >> >>>> >> >>>> Regards >> >>>> >> >>>> Sam >> >>>> Amateur Radio Callsign: VK4FQ / VK4TTT >> >>>> Owner: VK4RCN P25 Repeater Cairns >> >>>> Sysop: APRS Cairns >> >>>> Mobile: VK4FQ-9 (vhf) VK4FQ-15 (Hf) >> >>>> _________________________________________ >> >>>> 44Net mailing list >> >>>> 44Net(a)hamradio.ucsd.edu >> >>>> http://hamradio.ucsd.edu/mailman/listinfo/44net >> >>>> http://www.ampr.org/donate.html >> >>> >> >>> _________________________________________ >> >>> 44Net mailing list >> >>> 44Net(a)hamradio.ucsd.edu >> >>> http://hamradio.ucsd.edu/mailman/listinfo/44net >> >>> http://www.ampr.org/donate.html >> >> >> >> _________________________________________ >> >> 44Net mailing list >> >> 44Net(a)hamradio.ucsd.edu >> >> http://hamradio.ucsd.edu/mailman/listinfo/44net >> >> http://www.ampr.org/donate.html >> >

Matt the problem will also be some of 44 will be directly connected to the Internet(not thur UCSD) if they have any route to the net the local DNS could cause conflict or just a miss configured router. Just like a few companies have had when using 1.X.x.x as a private LAN. It was Allocated to the US DoD I think, but it looks to have been released now. A mis configured router drew quite a bit of attention from them as you can imagine. I still see 1.1.1.1 used a lot as an interrupt login page at hotels, ect for free or pay Internet. My understanding is that there may be some rouge direct connected 44 address ranges out there too. This is from a friend at a national CATV/ISP provider. I don't remember the specifics but prior to the policy Change by AMPR regarding this allocation we found some of these in their AS. If memory serves some were in VK. This is some thing we really need to run down.... With 16million addresses this is a hard task to police. I am guessing that ISPs have whole groups that just deal with rouge networks in their IP space. Just running a scan is not going to work as most ISPs will shut ya down if you tried to scan a whole class A. It really needs to be looked at in a AS. Not Brian's at UCSD as his will be correct. Lin N4YCI -- Lin Holcomb Office: +1 404 806 5412 Mobile: +1 404 933 1595 Fax: +1 404 348 4250

On 07/13/2013 07:23 PM, Cory (NQ1E) wrote: Hi, I am the current maintainer of the Swedish subnet 44.140.0.0/16 (se.ampr.org). The Swedish University Network (SUNET, AS 1653) agreed (with Brian's permission) to provide Internet transit for the entire network, which is initially announced out of a research network at KTH (AS8973), one of the universities connected to SUNET. We are slowly but surely distributing gateways to the 256 /24-networks over the country, located at an institution connected to SUNET and maintained by a licensed radio amateur associated with a local club, so that as many radio amateurs as possible can reach at least one of them via radio without tunneling. The basic agreements were arranged a few months ago. Things take time and we so far have only obe gateway up and running, at KTH in Stockholm (SK0WE). Another one (44.140.47.0/24) is coming up in August at the Technical Museum of Stockholm (SK0TM) and we have preparations in progress in almost all of the eight radio amateur districts of Sweden. If an opportunity opens to have an intradomain link to another AMPR subnet, we will take it, but all addresses in use can be reached via Internet transit. At an earlier stage of the restart of AMPRnet, I advocated going for an own AS number for AMPRnet, but I guess the way things have worked out for us is perfectly OK. I am working with a few amatuer colleagues and academic institutions in some African countries to replicate this model to be used for specific applications. One of them is to make environment data publicly available on the web. Bjorn/SA0BXI

There is still an entry for 44.140.0.0/16 in the encap.txt what gives a problem in that case. route addprivate 44.140/16 encap 90.225.73.203 Gateway maintained by Pontus Falk SM0RUX 73, Bob/Boudewijn VE3TOK On 13-07-13 02:44 PM, Bjorn Pehrson wrote:

It is a really a problem because that entry overrides the default. Maybe Chris can remove it. 73, Bob/Boudewijn VE3TOK On 13-07-13 04:59 PM, Bjorn Pehrson wrote:

Done On 14 Jul 2013, at 09:58, Bjorn Pehrson &lt;bpehrson(a)kth.se&gt; wrote:

In the case of 44.24.240/20, we were seeing issues where traffic from some networks (including google) wasn't making it back to our ASN for some reason. I was theorizing that perhaps our more specific BGP announcement wasn't being seen/honored in some circumstances in favor of the more generic 44/8 one. We intentionally setup the IPIP tunnels as an experiment and haven't had that trouble since. I suppose I need to shut that down and see if the problem returns to know for sure. Either way, we're in the encap file intentionally and you don't need to remove it. On Sat, Jul 13, 2013 at 4:04 PM, Bob Tenty &lt;bobtenty(a)gmail.com&gt; wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > There are more subnets who are announcing themselfs over Internet with BGP > and who are still in the encap.txt > > route addprivate 44.24.240/20 encap 198.178.136.80 > route addprivate 44.130.99/24 encap 193.22.2.254 > route addprivate 44.136.150/24 encap 203.55.214.21 > route addprivate 44.136.151/24 encap 203.55.214.21 > route addprivate 44.208/16 encap 94.101.48.134 > > This will give a problem if your commercial gateway address has changed > as in that case we can't reach your subnet. > (If I don't remove them manually) > > $curl -s http://thyme.rand.apnic.net/current/data-add-ARIN | grep " > 44\." > 7377 44.0.0.0/8 > 226 44.16.15.0/24 > 32915 44.24.240.0/20 > 12637 44.68.52.0/24 > 8121 44.74.128.0/24 > 61337 44.127.128.0/24 > 28748 44.130.99.0/24 > 56129 44.136.150.0/24 > 56129 44.136.151.0/24 > 8973 44.140.0.0/16 > 1653 44.140.47.0/24 > 39120 44.208.0.0/16 > > > > Bob/Boudewijn VE3TOK > > > >It is a really a problem because that entry overrides the default. > >Maybe Chris can remove it. > > >73, > > <Bob/Boudewijn VE3TOK > > > On 13-07-13 04:59 PM, Bjorn Pehrson wrote: > > Well, that is history and should eventually be cleaned up and > > archived, I guess. > > As far as I am aware, this does currently not create a problem. > > When I pointed it out to Brian, he seemed to have the same opinion. > > Pontus was the previous maintainer and handed it over to me. > > If you look into the new data base at > > https://portal.ampr.org/networks.php you will find me there. > > Bjorn > > > > On 07/13/2013 10:29 PM, Bob Tenty wrote: > >> (Please trim inclusions from previous messages) > >> _______________________________________________ > >> There is still an entry for 44.140.0.0/16 in the encap.txt > >> what gives a problem in that case. > >> > >> route addprivate 44.140/16 encap 90.225.73.203 > >> Gateway maintained by Pontus Falk SM0RUX > >> > >> 73, > >> > >> Bob/Boudewijn VE3TOK > >> > >> > > > >

In the case of 44.136.150/23 this was supposed to be deleted from the gateway file ages ago when I removed it as a gateway in the portal - obvious there is a bug in the code LOL Sam ----- Original Message ----- From: "Bob Tenty" &lt;bobtenty(a)gmail.com&gt; To: "AMPRNet working group" &lt;44net(a)hamradio.ucsd.edu&gt; Sent: Sunday, July 14, 2013 9:04 AM Subject: Re: [44net] Re Networks in OZ > (Please trim inclusions from previous messages) > _______________________________________________ > There are more subnets who are announcing themselfs over Internet with BGP > and who are still in the encap.txt > > route addprivate 44.24.240/20 encap 198.178.136.80 > route addprivate 44.130.99/24 encap 193.22.2.254 > route addprivate 44.136.150/24 encap 203.55.214.21 > route addprivate 44.136.151/24 encap 203.55.214.21 > route addprivate 44.208/16 encap 94.101.48.134 > > This will give a problem if your commercial gateway address has changed > as in that case we can't reach your subnet. > (If I don't remove them manually) > > $curl -s http://thyme.rand.apnic.net/current/data-add-ARIN | grep " 44\." > 7377 44.0.0.0/8 > 226 44.16.15.0/24 > 32915 44.24.240.0/20 > 12637 44.68.52.0/24 > 8121 44.74.128.0/24 > 61337 44.127.128.0/24 > 28748 44.130.99.0/24 > 56129 44.136.150.0/24 > 56129 44.136.151.0/24 > 8973 44.140.0.0/16 > 1653 44.140.47.0/24 > 39120 44.208.0.0/16 > > > > Bob/Boudewijn VE3TOK > > >>It is a really a problem because that entry overrides the default. >>Maybe Chris can remove it. > >>73, > > <Bob/Boudewijn VE3TOK > > > On 13-07-13 04:59 PM, Bjorn Pehrson wrote: >> Well, that is history and should eventually be cleaned up and >> archived, I guess. >> As far as I am aware, this does currently not create a problem. >> When I pointed it out to Brian, he seemed to have the same opinion. >> Pontus was the previous maintainer and handed it over to me. >> If you look into the new data base at >> https://portal.ampr.org/networks.php you will find me there. >> Bjorn >> >> On 07/13/2013 10:29 PM, Bob Tenty wrote: >>> (Please trim inclusions from previous messages) >>> _______________________________________________ >>> There is still an entry for 44.140.0.0/16 in the encap.txt >>> what gives a problem in that case. >>> >>> route addprivate 44.140/16 encap 90.225.73.203 >>> Gateway maintained by Pontus Falk SM0RUX >>> >>> 73, >>> >>> Bob/Boudewijn VE3TOK >>> >>> >> > >

On Sun, Jul 14, 2013 at 2:04 AM, Bob Tenty &lt;bobtenty(a)gmail.com&gt; wrote: But but... I think they absolutely must stay in encap.txt even if a BGP announcement is place! If they're removed, most of other traditional amprnet sites, which are not announcing their own network using BGP, cannot send packets to the BGP sites due to source address filtering (spoof protection). Most gateways these days must send out all 44-to-44 traffic encapsulated because they're only allowed to transmit out packets with their gateway's public address as the source address of the outer IP packet. - Hessu

On Mon, Jul 15, 2013 at 11:21 AM, Bob Tenty &lt;bobtenty(a)gmail.com&gt; wrote: I'm sorry, but I don't quite understand. If a subnet is not in encap.txt, the tunnel router in UCSD will not tunnel packets to that specific gateway - it's not much different than any other gateway in that respect, it gets its encap routing table from the very same gateways database. It doesn't have any magic deeper knowledge outside encap.txt. Maybe, if you updated your own encap routing table very rarely, you could send unknown traffic to UCSD and hope that it updates more often, but even then: I don't see any reason to remove BGP-announced subnets from encap.txt *except* at gateways which are doing BGP themselves or are otherwise certain that they can send out unencapsulated packets with their own net-44 source addresses. Most sites, these days, won't be able to do that, and they'll need to learn the net-44 tunnel routes somehow even for the BGP announced sites.

Heikki, But I could (IPIP) tunnel my 44 address back to UCSD and UCSD would route that in a normal way like every other Internet address back to those who make the announcements My mistake, UCSD would not tunnel but route in a normal way back over Internet to those gateways. So no entry in the encap.txt is needed for Gateways making BGP announcements. Bob VE3TOK On 13-07-16 09:22 AM, Heikki Hannikainen wrote:

To me, the reason for having more than one peering point is not only to avoid a singular point of failure, but also all sorts of performance and security issues. Besides robustness, it is about keeping local traffic local. There should be a route between all amprnet addresses in different non-directly connected subnet islands, either via Internet, if the spaces of the different islands are only announced via eBGP, or via intranet links on a per network level, tunnels or direct links whatever, in which case border routers should inform each other via iBGP and all be encap/decap-capable to satisfy anti-spoofing filters. As long as this is properly managed to avoid routing loops, asymmetric routing, etc, we should be able to mix them if there is a reason to do so. I would be prepared to participate in tests of schemes for this if anyone is interested. I am also keeping my eyes open for opportunities of having direct intranet links to other ampr islands. On 07/16/2013 05:00 PM, Brian Kantor wrote:

I just think the deal is we really should not be required to do something that we dont have as a project goal. If a BGP site wants to play in the amprgw world great if not then then no. That is like saying your FM radio must also be able to receive SSB to opperate on the 440mhz band. Maybe we dont want to do SSB or incur the extra complexity and cost. I think the idea is these are not the same projects they just use the same "band" IP space there is a plan to divide the sub nets up so that it is easy to see that whole class Bs or what ever is allocated is not necessarily going to be accessible unless you specifically make changes to the apmprgw system. It is not necessary for the packets to route back and forth. It just adds an extra level of complexity that is not needed for our project goals of hosting radio projects that are fully rotatable to the internet. Lin On Tue, Jul 16, 2013 at 2:35 PM, Heikki Hannikainen &lt;hessu(a)hes.iki.fi&gt; wrote: -- Lin Holcomb Office: +1 404 806 5412 Mobile: +1 404 933 1595 Fax: +1 404 348 4250

On Tue, Jul 16, 2013 at 09:35:03PM +0300, Heikki Hannikainen wrote: It's supposed to get routed out unencapsulated. I haven't tested that to make sure it works. I think it should, for network efficiency and robustness. Perhaps we should make that a required part of the network architecture? - Brian

On Tue, Jul 16, 2013 at 10:59:10PM +0300, Heikki Hannikainen wrote: That is precisely what's happening. 137.110.222.1 is an internal router with no BGP so it'll never learn about those directly-connected subnets. - Brian

On Mon, 15 Jul 2013, Heikki Hannikainen wrote: Existance of a route in the encap file implies there is a tunnel established at the other end willing to accept the encapsulated traffic. The sites doing BGP may or may not be doing that. If the latter, then you're just sending traffic to a black hole. Most gateways don't have visibility into the core routing tables. As you already mentioned, due to upstream service providers doing uRPF filtering, 44-to-any traffic must be tunneled through a gateway. For the non-encap net-44 destinations that means tunnelling through the UCSD gateway. You will need to setup a default (not just net-44) encap route pointing to UCSD but apply it only to traffic sourced from net-44 hosts - ie. policy routing for net-44. Antonio Querubin e-mail: tony(a)lavanauts.org xmpp: antonioquerubin(a)gmail.com

On Mon, 15 Jul 2013, Lin Holcomb wrote: Of course it is but not everyone can convince their upstream to route their net-44 prefixes in their route tables and announce them via BGP. If that were easy, we wouldn't have the encap table we have today. Antonio Querubin e-mail: tony(a)lavanauts.org xmpp: antonioquerubin(a)gmail.com

On Mon, Jul 15, 2013 at 11:27 PM, Antonio Querubin &lt;tony(a)lavanauts.org&gt; wrote: I would suggest that all of the BGP-enabled sites should have tunnel endpoints like before, so that all the old non-BGP net-44 sites can talk directly to the BGP sites, even when they old sites are behind uRPF/spoofing filters and cannot transmit unencapsulated net-44 traffic. If one of the major reasons to do BGP announcements in the first place is to reduce traffic going via UCSD, then it makes a lot of sense to keep the old tunnel endpoints in place, and not have all traffic from non-BGP sites to BGP sites go via UCSD. It's good for latency and resiliency. - Hessu

Cory There are a few others that use 55707 and a few more for 56129 waiting for upstream to allow them Sam ----- Original Message ----- From: "Cory (NQ1E)" &lt;cory(a)nq1e.hm&gt; To: &lt;lholcomb(a)clearqualitygroup.com&gt;om>; "AMPRNet working group" &lt;44net(a)hamradio.ucsd.edu&gt; Sent: Sunday, July 14, 2013 3:23 AM Subject: Re: [44net] Re Networks in OZ > (Please trim inclusions from previous messages) > _______________________________________________ >> there may be some rouge direct connected 44 address ranges out there too. > > All of the BGP announcements on the internet that include 44 space are > listed below. Brian says they are all accounted for. I assume that means > each of those subnets are registered in the portal. > > # curl -s http://thyme.rand.apnic.net/current/data-add-ARIN | grep " 44\." > 7377 44.0.0.0/8 > 226 44.16.15.0/24 > 32915 44.24.240.0/20 > 12637 44.68.52.0/24 > 8121 44.74.128.0/24 > 61337 44.127.128.0/24 > 28748 44.130.99.0/24 > 56129 44.136.150.0/24 > 56129 44.136.151.0/24 > 8973 44.140.0.0/16 > 1653 44.140.47.0/24 > 39120 44.208.0.0/16 >

I think they are waiting for upstream to do there filtering ----- Original Message ----- From: "Cory (NQ1E)" &lt;cory(a)nq1e.hm&gt; To: "AMPRNet working group" &lt;44net(a)hamradio.ucsd.edu&gt; Sent: Monday, July 15, 2013 8:46 AM Subject: Re: [44net] Re Networks in OZ > (Please trim inclusions from previous messages) > _______________________________________________ >> There are a few others that use 55707 > > Sam, > > If 55707 is announcing 44 blocks, they don't appear to be globally > visible. > Here's what's visable from that AS right now: > > # curl -s http://thyme.rand.apnic.net/current/data-ASnet-detail | sed -n > '/^55707/,/^\w/ p' > 55707 > 101.2.168.0/22 > 103.1.108.0/22 > 103.5.88.0/24 > 223.25.112.0/23 > 223.25.112.0/22 > 223.25.118.0/23 >

On Fri, 2013-07-12 at 14:18 -0700, K7VE - John wrote: That's what I've been trying to do in the various subnets within 1-land. So far those I knew who had addresses have given up on 44-net because while they point fingers at us that 44-net doesn't work, when infact -they- don't know how to configure an ipip tunnel. -- Brian Rogers Phone: 860-673-4537 Email: n1uro(a)gmx.com Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org/ Platform: Linux URONode/axMail-Fax created here! Coordinator for: 1-land, DE, and N.J AmprNet