As well all of a advertised block must me advertised only from a single asn. This is where this will start to get tricky.
Sent from my Windows Phone
________________________________
From: Michael Fox - N6MEF
Sent: 2012-03-16 12:56
To: 'AMPRNet working group'
Subject: Re: [44net] directly routed subnets
(Please trim inclusions from previous messages)
_______________________________________________
There are different levels of peering.
The policies below describe tier 1/2 peering between the big guys. Most
peering relationships are not at that level.
Many small businesses have peering with more than one service provider.
It's quite common. The current startup I work for has a /24 that they
announce to their colo provider in San Francisco, as well as the ISP that
serves their HQ location further down the peninsula. (The colo and their HQ
are tied together as one ASN).
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 Tim
Pozar
Sent: Friday, March 16, 2012 9:43 AM
To: AMPRNet working group
Subject: Re: [44net] directly routed subnets
(Please trim inclusions from previous messages)
_______________________________________________
On Mar 16, 2012, at 8:20 AM, Brian Kantor wrote:
> Perhaps I should start collecting AUPs from various sources rather
> than having to create one from scratch.
>
> URLs to model AUPs would be appreciated.
In concern of BGP peering...
You can see some of the hoops that ARIN requires for an ASN at:
https://www.arin.net/policy/nrpm.html
See section 5 <https://www.arin.net/policy/nrpm.html#five> for ASN
requirements.
Certainly there are policies for peering that other ASNs. Some of these
policies are good to look at for requirements for announcing address space.
Some of the requirements are a bit onerous and don't apply. Comcast has
their set of requirements at:
http://www.comcast.com/peering/
Certainly things like "Applicant must operate a US-wide IP backbone whose
links are primarily 10 Gbps or greater" should not be a requirement. But
points like:
* Applicant must have a professionally managed 24x7 NOC and agree to
repair or otherwise remedy any problems within a reasonable timeframe.
Applicant must also agree to actively cooperate to resolve security
incidents, denial of service attacks, and other operational problems.
or
* Applicant must maintain responsive abuse contacts for reporting
and dealing with UCE (Unsolicited Commercial Email), technical contact
information for capacity planning and provisioning and administrative
contacts for all legal notices.
may be a good idea. The latter one would be needed to help resolve
poisoning of address space and getting listed on various RBLs.
Other sites that have peering requirements can be seen at:
ATT - http://www.corp.att.com/peering/
Verizon - http://www.verizonbusiness.com/terms/peering/
AOL - http://www.atdn.net/settlement_free_int.shtml
MFN/Abovenet - http://www.above.net/peering/
If folks want can make a stab at a draft for requirements for someone
announcing 44/8 space.
Tim
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
Brian and All,
I always thought it was a waste of a routable /8 to not have it routed
on the Internet, otherwise why are people just not using IANA space instead?
However, if it is to be routed on the internet I think some ground rules must
be established of what is and is not acceptable and penalties for not following
the rules and established guidelines.
Additionally, and I bring this up again, a RWHOIS server should/must be
used (tied in with ARIN on the 44/8 allocation) so that people can query
specific address space that will return the contact/owner of whatever space is
being advertised for whatever reason. Additionally, IRR entries should also be
required for anyone wanting to advertise space via BGP. Those should be some
common sence polices that need to be followed at the very minimum.
Obviously nothing smaller then a /24 should be advertised on the
internet as most Tier 1 carriers will block any address space that is smaller
in their BGP configs. I don't know what the whole breakup of space looks like
within each coordinator's /16 space (for those that have a /16 of space), but I
would think there surely is space in each that could be a usable /24 or larger
that could be utilized for that. Alternatively there seems to be a lot of space
at the upper end of the 44 block that could be used for internet routed blocks
if we wanted to use that first?
IP Space justification will be whole issue within it's self as well,
because if you only REALLY need /28 or /27 of IP's, one will still need to
advertise a /24. Perhaps who ever advertises space via BGP should accept the
condition that if only a portion of the advertise space is being used that you
will accept and allow another person needing the available space so that it's
not wasted. This could be tracked and allocated via the rwhois server in
conjunction with entries in IRR.
UCSD can still advertise the 44/8, and of course if anyone advertises a
more specific route, that will be preferred of the larger aggregate.
Be nice if we were all on a IRC chat channel to bounce ideas around? If
anyone is interested, how about channel #44net on IRC server network freenode
(irc.freenode.net). I'm on there now.
Tim Osburn
www.osburn.com
206.812.6214
W7RSZ
On Tue, 6 Mar 2012, Brian Kantor wrote:
> Date: Tue, 6 Mar 2012 11:14:57 -0800
> From: Brian Kantor <Brian(a)ucsd.edu>
> Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> To: 44net(a)hamradio.ucsd.edu
> Subject: [44net] directly routed subnets
>
> I've gotten several requests for directly routed subnets (ie, BGP announced
> CIDR blocks as subnets of 44/8, not tunneled) for ham radio use. These are
> people who want to set up HSMM networks in the ham bands, D-Star
> constellations, etc.
>
> I thought I'd ask folks what they think of the idea of setting aside part of
> the address space for that purpose?
>
> What issues do you see arising from doing so?
> - Brian
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
I'm also using a standard Ubuntu Linux Server 11.10 using rip44d and a Web Application providing a GUI named Webmin. This is a quick overview on setup.
This setup can be done with telent and SSH; for simplicity of those who know the command line syntax, I will omit the necessaries.
1.) - with IP forwarding (Routing) enabled in /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
2.) - I installed webmin (a Web GUI application for servers) package to better enable on the fly IPtables Firewall configurations, NAT, masquerade, etc. (these configurations allowed me to have this server as router for my 44.60.44/24 subnet over AMPR, while having the ability to also have a private 192.168/24 subnet that uses my standard non-tunneled gateway IP address from my ISP. PE1CHL recommended table-based policy routing; it configures any 44/8 address to use a routing tabled named "44," all other traffic is routed on main. If you setup this router to use NAT or Masquerade for a private network using your ISP's gateway, there will also be entries in the "nat" table. An edit to the rip44d script is necessary to place the 44/8 routes into a routing table named "table 44."
3.) - eth0 was configured at setup as the device connected to the Gateway address.
4.) - In this example, eth1 is the Ethernet interface that will be used as you LAN side providing your 44 Addresses (in this example 44.128.0.0/24) of the router connection (if you do not have access to another NIC, you may also want to set this up virtually to the address on your LAN if this is not the routing device for your physical network). Interface tunl0 is the default Linux IPIP encapsulation tunnel. The example/testing subnet 44.128.0.0/24 will be the subnet assigned to the gateway on tunl0 and eth1 used here.
5.) - with the help of Brian and PE1CHL, I then created a script named /usr/local/sbin/startampr to run on boot (it can be setup to run at boot in the webmin GUI under "Bootup and Shutdown"
### Enables AMPR IPIP Tunnel Interface
modprobe ipip
ip addr add 44.128.0.2/24 dev tunl0
# gives tunnel its own TTL enabling traceroute over tunnel
ip tunnel change ttl 64 mode ipip tunl0
ip link set dev tunl0 up
### Creates AMPR Default Routes on main Route Table
#route to 44.128.0.0/24 on main route table
ip rule add to 44.128.0.0/24 table main priority 1
### Specifies Routes to and from 44/8 are entered on Route Table 44
ip rule add from 44.0.0.0/8 table 44 priority 44
ip rule add to 44.0.0.0/8 table 44 priority 45
### Creates Default Route to the AMPRGW and the
### Internet At-large, on the 44 Router
## Per PE1CHL: 'This is "required" to get routing of the net-44 traffic correct
## and have a default route for the tunneled traffic different from the default
## route of the system. It may be possible to get it working without this,
## but policy based routing is so much easier'
# AMPRGW connects via eth0
ip route add 169.228.66.251 dev eth0 table 44
# Connection to 0/0 by 44/8 Hosts on AMPRGW, commenting disables Internet Access for your 44 subnet
ip route add default dev tunl0 via 169.228.66.251 onlink table 44
### this can be omitted if your device will not provide separate local traffic - KB3VWG - This adds a route to the local subnet on the 44 route table
ip route add 192.168.0.0/24 dev eth0 table 44
### Begins the rip44d Router
./usr/local/sbin/rip44d_table44 -a <my public gateway IP> -p <the password> < /dev/null &
6.) Table rip44d_table44 is a script editing the rip44d file to place the AMPR routing table into "Table 44":
Line 201
- $cmd = "LANG=C $routebin route add $rkey via $nexthop dev $tunnel_if window $tcp_window onlink";
+ $cmd = "LANG=C $routebin route add $rkey via $nexthop dev $tunnel_if window $tcp_window onlink table 44";
7.) The routers 'main' Firewall
Accept If state of connection is ESTABLISHED
Accept If state of connection is RELATED
* Accept If protocol is ICMP and ICMP type is echo-request
* Accept If protocol is UDP and destination port is 33434:33534
+ Accept If protocol is TCP and destination port is 10000
+ Accept If protocol is UDP and source is 44.0.0.1 and input interface is tunl0 and source and destination ports are 520
+ Accept If protocol is TCP and destination destination port is 22
(if you have other services on your Router machine, you would accept their IP's, source, destinations, etc. here)
+ - enables: webmin, rip44d and SSH respectively, you may further restrict this access to SSH or Webmin configuration by specifying allowed hosts, subnets, etc.
8.) IP Forwarding [the Router's] Firewall
Accept If state of connection is ESTABLISHED
Accept If state of connection is RELATED
* Accept If protocol is ICMP and ICMP type is echo-request
* Accept If protocol is UDP and destination port is 33434:33534
Accept If source is 44.128.0.0/24
Accept If source is 192.168.0.0/24
(if you have services on devices inside your subnet, you would accept their destination IP's ports, source, destination ports, etc.)
9.) Network Address Translation Firewall (only needed if routing traffic from a private network [eg 192.168.0.0/24] not carrying 44 Traffic)
Accept If source is 192.168.0.0/24 and destination is 44.128.0.0/24
Masquerade If source is 192.168.0.0/24 and destination is 0.0.0.0/0
Accept If source is 44.128.0.0/24
Accept If destination is 44.128.0.0/24
10.) as you create AX.25 interfaces, etc, ensure you enable those protocols, etc in the firewalls.
NOTE: Accepting echo-request and protocol is UDP ports 33434-33534 enable Unix and windows based ping and traceroutes from the Internet, you can also place further restrictions on those rules.
11.) Typing the command
# ip route list table 44
default via 169.228.66.251 dev tunl0 onlink
<between here should be many lines of 44.x.x.x direct IPIP Encapsulated routes that are populated by rip44d from 44.0.0.1 over the tunnel (e.g. '44.x.x.x/x via x.x.x.x dev tunl0 onlink window 840')>
169.228.66.251 dev eth0 scope link
192.168.0.0/24 dev eth0 scope link
~73,
KB3VWG
All,
I actually had a thought on this before I read the current line of discussion. Alot has been highlighted on the nature of a 501(c)3 and what it can and cannot do (feel free to read up on the IRS.gov publications). A 501(c)7 is also a route we may wish to take (depending on California Law and if the filing for determination process had not already proceeded). I also noted that keeping it for Amateur use by Hams is a very good idea.
Also recall that we need to keep the network flexible, as testing and development of new protocols and types of equipment, etc. is also something that may become of interest in the future. Also, if you are going to announce space, I am capable of having it housed; so agreements regarding equipment, etc. would be on an Intergovernmental network in my area that RACES and local Emergency Radio Foundation will petition for a seat on, we don't happen to have any carrier-grade network equipment in our shacks on the East Coast (lol).. HSMM-MESH seems like something we want to experiment on right now.
In addition, we peer with non-commercial networks; NetworkMaryland is the ISP that we wish to approach for holding an announcement. And it will be Internally BGPed to my County. I'd like to talk with my State Coordinator about this. I know that we are a network neighbour to the Internet2.edu backbone and other carries as well.
~73,
Lynwood
KB3VWG
44.60.44/24
I've gotten several requests for directly routed subnets
(ie, BGP announced CIDR blocks as subnets of 44/8, not tunneled)
for ham radio use. These are people who want to set up HSMM
networks in the ham bands, D-Star constellations, etc.
I thought I'd ask folks what they think of the idea of
setting aside part of the address space for that purpose?
What issues do you see arising from doing so?
- Brian
Hi N7VR
I have to alter for Gateway IP I send mail there now copies, that bad password
I ask about switch because your mail server n7vr throws aside my mail's
<<< 450 4.7.1<n7vr(a)n7vr.org>: Recipient address rejected: IP still greylisted - Please try again later
<n7vr(a)n7vr.org>... Deferred: 450 4.7.1<n7vr(a)n7vr.org>: Recipient address rejected: IP still greylisted - Please try again later
--
73 de Janusz / SP1LOP
===== Janusz J. Przybylski, SP1LOP ==========
Poland AmprNet Co-ordinator [44.165.0.0/16]
=============================================
Bill,
Thanks, I have installed multiple versions of JRE, I'm currently using Oracle JRE 1.7.0_03, still a connection reset to the analyser and any pages served on the domain http://netalyzr.icsi.berkeley.edu So, it's not simply a Java issue, as accessing non-Java content returns the same error. I'm using Linux w/ a firewall, so no Anti-Virus/Malware running preventing the connection. I can browse to the page if I connect the device a the non 44 node at my home QTH.
I should note all other sites needing JRE to run (such as the Test your Java Page) work perfectly fine on all other network connections, all devices, with all versions of JRE tested, this only occurs if the device is connected to 44net.
I just wanted to verify that the results you noted to me were obtained over the 44 connection before I contact Berkley.edu about inability to access the tool.
~Lynwood
KB3VWG
I've received a request regarding AMPRNet activity in Sweden.
The email address I have for the coordinator there dates from
back in 2000 and is no longer valid.
There are over 1000 DNS entries for the 44.140 Swedish subnet;
surely somebody must still be active.
Any information would be appreciated.
- Brian
All,
Does anyone receive connection reset when navigating to http://netalyzr.icsi.berkeley.edu
I wanted to examine my connection (and perhaps determine the source of my random packet loss [between 5-10%]).
~73,
Lynwood
KB3VWG
On Sun, Feb 26, 2012 at 3:44 PM, Chris Maness <chris(a)chrismaness.com> wrote:
> On Sun, Feb 26, 2012 at 12:01 PM, Raymond Quinn <w6ray(a)sbcglobal.net> wrote:
>> Hmmm. I see you have a link with Brett, WA7V.
>>
>> He also has static addresses, and was able to assign a commercial IP address
>> to his linux box, as well as his NOS side.
>>
>> You might want to consult him on how that is done.
>>
>> In the mean time, does your JNOS have a LAN address of 192.168.x.x ??
>>
>> It is behind a DSL Modem/Router. It is a 2wire. However, I have 5 static
>> IPs. It does not allow me to use one of the public IPs for Jnos. It does
>> not add that IP to the local network list for configuration, and therfore
>> does not permit traffic to Jnos. I therfore had to use the munge script to
>> build tunnels in Linux. This is ok, because it does protect Jnos from
>> attacks.
>>
>>
>> Chris,
>>
>> It appears that you have the same or quite similar setup that I have. I have
>> my Linux box with a public static IP address and use that in the POINTOPOINT
>> line. Eventually, the Linux box will appear in the 2wire and when it does,
>> should automatically allow all traffic to that static address.
>
> It does exactly that.
>
>>
>> (Of course, at present JNOS is locking up after a few hours, but that is
>> unrelated)
>>
>> If you don't hear from Brett, I am willing to share what I have worked out.
>> I still have more to do, but it may get you started. As always, make sure
>> you make a backup of your current setup should it not work as mine does.
>>
>
> It works just fine save one host on AMPR-NET. I wouldn't care save he
> is my friend and one of the closest *NOS BBS to my site.
>
> I had also been in touch with AT&T customer service. The suggested I
> purchase a Motorola router from them. I wish my Linux box was back
> behind a Cisco on a commercial T1 like it was in the beginning. I had
> direct 44net-to-inet connectivity. However, the AT&T network is
> controlled by the packet Gustapo goose stepping with their tight
> firewall rules. I guess that is good for the brain dead masses, but
> it kind of makes playing with the stuff we do a pain in the toosh.
>
> Thaks es 73's
> de Chris KQ6UP
My Linux box can ping his Linux box, so that is good. I am not sure I
have the whole doted quad with a forward slash business down. I think
this is his encap.txt entry:
route addprivate 44.16.2.32/27 encap 173.60.166.190
Since I believe that 44.16.2.46 is included in that subnet. Is the
above subnet 44.16.2.32-64?
Thanks,
Chris Maness
