If you’re ever interested in what’s being advertised you can always check a “route view” server. If you google “route view” server you’ll get a big list. I normally use “route-views.optus.net.au” because it’s close to me and a cisco. you can then telnet to it without having to log in: telnet route-views.optus.net.au then when you’re in you can issue a “show route” command. For example: show ip route 44.0.0.0 longer-prefixes This will give you all the 44net’s advertised out to the internet. If you’re interested in digging into the bgp specifics you can pick a network and issue this command: show ip bgp 44.140.64.0/23 This will give you the AS paths and bgp routes to 44.140.64.0/23 along with some metrics. Cheers Pete ZL1PCM On 1/04/2014, at 9:58 am, Michael E Fox - N6MEF <n6mef(a)mefox.org> wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Steve, > > Huh? AMPRnet is already routed. > > The entire 44.x space is already reachable from anywhere on the Internet via > the BGP peer router at UCSD. And I understand portions are also announced > via BGP elsewhere (mostly in Europe, as I understand it). So in that > respect, it's no different than any other public address allocation to a > global entity that announces a prefix with BGP at the "home office" and > (optionally) longer prefixes elsewhere. > > But the entire AMPRnet is not contiguous except by the use of tunnels. > Connectivity within the local "islands" is routed. We happen to use a > combination of RIP (where needed) and OSPF in our part of the network. And > connectivity between the islands is routed over tunnel interfaces. The > options there are static or RIP. Again, this is not much different than a > corporation that uses VPN tunnels between sites. A tunnel is just another > interface to a router. Tunneling does NOT indicate a lack of routing. > > The 44.x address space allows globally unique addressing within the ham > community. It would be impossible to do that with network 10 since it is > already used for other private address space. There is simply no way to > deal with all of the address overlaps. Surely anyone with even basic IP > routing knowledge can understand this. > > So I don't understand what your concern is. What specific problem are you > trying to solve? In other words, what is it (specifically) that you can't > do today with the existing infrastructure? > > Also, what type of services are you running today, and how many of each? > > Michael > N6MEF > > > -----Original Message----- > From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu > [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Steve > Wright > Sent: Monday, March 31, 2014 1:05 PM > To: 44net(a)hamradio.ucsd.edu > Subject: [44net] routable or private? > > (Please trim inclusions from previous messages) > _______________________________________________ >> If this is, " a hack to backbone a semi-private network on top of the >> public internet" then why do we need 44/8? Please explain why 10/8 would >> not work just as well? >> >> [....] if it's not going to be routable then why do we need 44/8? use >> RFC1918 space and give 44/8 back. [...] We could attract many >> into this hobby if we'd simply offer to be the teachers of the IP >> networking craft using standards based methods used by everyone else > across >> the internet. >> > > PRECISELY. > > Can we please make a decision on this and move ahead? > > I'd like to know, one way or the other, because I sure aint interested in > all this private 44net stuff.. > > Is 44net routable or private? > > > > Steve >

Thats right. So all of these 44/8 networks have organised themselves a BGP peering to the internet. If you have a look at the “via xxx.xxx.xxx.xxx” part of the list below and put it into a geolocation service you can see where they are. e.g. http://www.ip2location.com/demo Like 44.136.138.0/24 via 114.31.199.1 is in Sydney Australia and the peering is to Vocus On 1/04/2014, at 10:34 am, Neil Johnson <neil.johnson(a)erudicon.com> wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Here is example output... > > show ip route 44.0.0.0 longer-prefixes > Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP > D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area > N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 > E1 - OSPF external type 1, E2 - OSPF external type 2 > i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 > ia - IS-IS inter area, * - candidate default, U - per-user static route > o - ODR, P - periodic downloaded static route > > Gateway of last resort is 128.223.51.1 to network 0.0.0.0 > > 44.0.0.0/8 is variably subnetted, 30 subnets, 8 masks > B 44.12.6.0/24 [20/31] via 129.250.0.11, 2d02h > B 44.0.0.0/8 [20/0] via 216.218.252.164, 7w0d > B 44.136.138.0/24 [20/0] via 114.31.199.1, 1w4d > B 44.136.139.0/24 [20/0] via 114.31.199.1, 1w4d > B 44.136.150.0/24 [20/0] via 114.31.199.1, 1w4d > B 44.136.151.0/24 [20/0] via 114.31.199.1, 1w4d > B 44.16.15.0/24 [20/0] via 114.31.199.1, 4w3d > B 44.136.158.0/24 [20/0] via 114.31.199.1, 1w5d > B 44.136.224.0/24 [20/0] via 114.31.199.1, 1w4d > B 44.136.227.0/24 [20/0] via 114.31.199.1, 1w4d > B 44.103.0.0/19 [20/0] via 216.218.252.164, 1w4d > B 44.68.52.0/24 [20/0] via 216.218.252.164, 4w1d > B 44.161.252.0/22 [20/0] via 216.218.252.164, 4w4d > B 44.34.128.0/21 [20/31] via 129.250.0.11, 2d02h > B 44.140.47.0/24 [20/0] via 217.75.96.60, 7w0d > B 44.140.0.0/16 [20/0] via 217.75.96.60, 6w1d > B 44.46.160.0/22 [20/0] via 4.69.184.193, 1w3d > B 44.139.0.0/16 [20/0] via 4.69.184.193, 1d10h > B 44.98.254.0/24 [20/0] via 4.69.184.193, 1w3d > B 44.169.48.0/20 [20/0] via 195.66.232.239, 1d10h > B 44.144.0.0/16 [20/10] via 89.149.178.10, 4w0d > B 44.24.240.0/20 [20/0] via 12.0.1.63, 2w4d > B 44.130.99.0/24 [20/0] via 216.218.252.164, 1w1d > B 44.135.120.0/24 [20/0] via 216.218.252.164, 7w0d > B 44.127.128.0/24 [20/0] via 216.218.252.164, 1w6d > B 44.140.64.0/23 [20/0] via 217.75.96.60, 00:30:13 > B 44.140.66.0/24 [20/0] via 217.75.96.60, 00:30:13 > B 44.74.128.0/24 [20/0] via 216.218.252.164, 2w4d > B 44.140.79.0/24 [20/0] via 217.75.96.60, 7w0d > B 44.208.0.0/16 [20/0] via 194.85.40.15, 3d20h > > On Mon, Mar 31, 2014 at 4:15 PM, Pete McCormick > <pete.mccormick(a)gmail.com> wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >> If you're ever interested in what's being advertised you can always check a "route view" server. If you google "route view" server you'll get a big list. I normally use "route-views.optus.net.au" because it's close to me and a cisco. >> >> you can then telnet to it without having to log in: >> telnet route-views.optus.net.au >> >> then when you're in you can issue a "show route" command. For example: >> >> show ip route 44.0.0.0 longer-prefixes >> >> This will give you all the 44net's advertised out to the internet. >> >> If you're interested in digging into the bgp specifics you can pick a network and issue this command: >> >> show ip bgp 44.140.64.0/23 >> >> This will give you the AS paths and bgp routes to 44.140.64.0/23 along with some metrics. >> >> Cheers >> >> Pete >> ZL1PCM >> >> >> >> >> >> >> On 1/04/2014, at 9:58 am, Michael E Fox - N6MEF <n6mef(a)mefox.org> wrote: >> >>> (Please trim inclusions from previous messages) >>> _______________________________________________ >>> Steve, >>> >>> Huh? AMPRnet is already routed. >>> >>> The entire 44.x space is already reachable from anywhere on the Internet via >>> the BGP peer router at UCSD. And I understand portions are also announced >>> via BGP elsewhere (mostly in Europe, as I understand it). So in that >>> respect, it's no different than any other public address allocation to a >>> global entity that announces a prefix with BGP at the "home office" and >>> (optionally) longer prefixes elsewhere. >>> >>> But the entire AMPRnet is not contiguous except by the use of tunnels. >>> Connectivity within the local "islands" is routed. We happen to use a >>> combination of RIP (where needed) and OSPF in our part of the network. And >>> connectivity between the islands is routed over tunnel interfaces. The >>> options there are static or RIP. Again, this is not much different than a >>> corporation that uses VPN tunnels between sites. A tunnel is just another >>> interface to a router. Tunneling does NOT indicate a lack of routing. >>> >>> The 44.x address space allows globally unique addressing within the ham >>> community. It would be impossible to do that with network 10 since it is >>> already used for other private address space. There is simply no way to >>> deal with all of the address overlaps. Surely anyone with even basic IP >>> routing knowledge can understand this. >>> >>> So I don't understand what your concern is. What specific problem are you >>> trying to solve? In other words, what is it (specifically) that you can't >>> do today with the existing infrastructure? >>> >>> Also, what type of services are you running today, and how many of each? >>> >>> Michael >>> N6MEF >>> >>> >>> -----Original Message----- >>> From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu >>> [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Steve >>> Wright >>> Sent: Monday, March 31, 2014 1:05 PM >>> To: 44net(a)hamradio.ucsd.edu >>> Subject: [44net] routable or private? >>> >>> (Please trim inclusions from previous messages) >>> _______________________________________________ >>>> If this is, " a hack to backbone a semi-private network on top of the >>>> public internet" then why do we need 44/8? Please explain why 10/8 would >>>> not work just as well? >>>> >>>> [....] if it's not going to be routable then why do we need 44/8? use >>>> RFC1918 space and give 44/8 back. [...] We could attract many >>>> into this hobby if we'd simply offer to be the teachers of the IP >>>> networking craft using standards based methods used by everyone else >>> across >>>> the internet. >>>> >>> >>> PRECISELY. >>> >>> Can we please make a decision on this and move ahead? >>> >>> I'd like to know, one way or the other, because I sure aint interested in >>> all this private 44net stuff.. >>> >>> Is 44net routable or private? >>> >>> >>> >>> Steve >>>

My mistake. Marc’s correct. you’d need to trace route to get the last gateway, then put that in a geolocation search Pete On 1/04/2014, at 11:11 am, Marc, LX1DUC <lx1duc(a)laru.lu> wrote:

My opinion - after years of experience and more years of net discussions... This is slightly changed after the discussions last week... It should be possible - but only in a highly filtered and controlled special case. As one example, I've been turning on MRTG traffic charts on the various home and radio subnets. That page could be something that would be of interest in the non-44 world and could be safely shared. It should be possible - more than the incoming case above but still carefully controlled. Recently I've come to appreciate more the corporate structure where outgoing access is somewhat controlled. Somethings I've seen on some systems are a bit scary. As long as you have 'users' there is potential for traffic violations. That's the small price we pay for doing cool things. There is probably no universal 'correct' policy. Everybody has to weigh all the consequences of their configuration. Bill, WA7NWP

I would like to chime in here with a couple points. 1. Not all 44-net traffic is routed over the air. This address space is indeed reserved for the amateur radio community, but that doesn't mean that it's routed over the air and is necessarily subject to the content rules the FCC has laid out for our wireless communications. In such situations, it makes little sense to restrict to only 44/8 space unless that is the only community you're serving. As bill said, there are certainly things that would be of interest to the outside world, and are part of the ham community so shouldn't be restricted. 2. For the traffic that does go over the air, consider the case of a repeater operator/owner, and say that repeater has a phone patch. The FCC has laid out rules that the operator of the repeater is not liable for the content of other's transmissions, provided they take reasonable corrective action to prevent abuse. Specifically in the case of a phone patch, in most cases, this means configuring it for only outgoing calls, however, it is permissible to receive a phone call from the outside provided it is expected by a licensed operator. If we apply this to IP space, this would translate in my mind to generally firewalling incoming traffic, allowing for exceptions in the firewall rules as desired for ham services that are compatible with the wireless nature of the path, and in my opinion, I'd prefer to not restrict other licensed users of a network. They're responsible for their own transmissions, and if it comes to be a problem, as in the case of a repeater, steps can be tak! en to limit or stop the abuse. So, in agreement with Bill, it's going to very much depend on your situation, as is the case with all internet connected systems, you need to protect it in the way that makes most sense for your applications of it. Nigel K7NVH On Apr 1, 2014, at 5:23 PM, Paula <g8pzt(a)blueyonder.co.uk> wrote:

OK, can someone tell me who is claiming ownership of 44.68.52.0/24? This is not a subnet that has been allocated in NY State per the portal. -- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Net Mon. @ 8:30PM 147.360/107.2 PL or 441.100/136.5 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB/1500 hz waterfall spot; Olivia 8/500 check-ins "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

Somethings not right ... I did a traceroute to 44.68.52.1 and 44.68.52.254 and this is what I received for both: traceroute 44.68.52.1 traceroute to 44.68.52.1 (44.68.52.1), 64 hops max, 52 byte packets 1 rtr-core-lc.net.uiowa.edu (128.255.204.1) 0.729 ms 3.193 ms 0.316 ms 2 rtr-border-lc.net.uiowa.edu (128.255.2.129) 1.226 ms 2.093 ms 0.363 ms 3 ae-3.718.chic0.tr-cps.internet2.edu (64.57.21.112) 5.119 ms 5.198 ms 5.093 ms 4 xe-2-2-0.0.ny0.tr-cps.internet2.edu (64.57.20.250) 36.735 ms 31.374 ms 31.416 ms 5 * * * 6 po2.asr1.lin1.gblx.net (67.16.149.98) 142.574 ms 142.598 ms 142.857 ms 7 seeweb-s-r-l.asr1.lin1.gblx.net (64.214.148.122) 123.499 ms 123.162 ms 123.203 ms 8 corsico.wiran.net (88.149.154.126) 135.288 ms 132.557 ms 135.058 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * The last hop (88.149.154.126) is address space in Italy ? WHO IS Data: This is the RIPE Database search service. The objects are in RPSL format. The RIPE Database is subject to Terms and Conditions. See http://www.ripe.net/db/support/db-terms-conditions.pdf inetnum: 88.149.154.0 - 88.149.155.255 netname: NGI-INFR1 descr: NGI Spa descr: Single Static IPs country: IT admin-c: LS1709-RIPE tech-c: AP5938-RIPE status: ASSIGNED PA mnt-by: NGI-MNT mnt-lower: NGI-MNT mnt-routes: NGI-MNT source: RIPE # Filtered person: Alberto Pasquale address: NGI S.p.A. address: Via Darwin, 85 address: I-20019 Settimo Milanese (MI) phone: +39 02 3700851 fax-no: +39 02 335170600 nic-hdl: AP5938-RIPE abuse-mailbox: abuse(a)ngi.it mnt-by: NGI-MNT source: RIPE # Filtered person: Luca Spada address: NGI SpA address: Via Gran San Bernardo, 12 address: I-21052 Busto Arsizio VA address: Italy phone: +39 02 3700851 nic-hdl: LS1709-RIPE mnt-by: NGI-MNT source: RIPE # Filtered UpdateDeleteMore Info from RIPEstat route: 88.149.128.0/17 descr: NGI origin: AS35612 mnt-by: NGI-MNT source: RIPE # Filtered Hmmm. On Tue, Apr 1, 2014 at 10:00 AM, Charles Hargrove <n2nov(a)n2nov.net> wrote: -- Neil Johnson http://erudicon.com

Frank, I work in IT professionally, and really the holdup is that IPv6 "is hard." Not that it's actually hard. I run IPv6 both professionally and personally, but it does take some effort to implement, it's dealt with somewhat differently than IPv4, and in some cases, could require new equipment to be able to handle it. Additionally, we have somewhat of a chicken and the egg problem. Major hosting providers aren't terribly inclined to go through all the above effort because very few consumers actually have v6 connectivity. And on the other side, many consumer ISPs haven't put much effort into getting their customers v6 connectivity due to few major hosting providers or web sites actually support it. Comcast has been for once doing something laudable, and has been pushing IPv6 deployment throughout their networks, and while it's not everywhere yet, they (as of the end of last year) had 25% of their quite substantial customer base enabled for IPv6 use. Hopefully, the rest of the industry will follow suit and we'll see IPv6 adoption pick up significant steam, both amongst hosting providers, as well as consumer ISPs. Nigel K7NVH On Apr 3, 2014, at 10:48 AM, sp2lob(a)tlen.pl wrote: