Holy smokes, we have Internet address space!
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 https://portal.ampr.org/networks.php?a=region&id=191 HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :) What an incredibly productive day, --Bart
Here's an IPv6 allocation for you ;) ::ffff:44.24.240.0/116 With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year. On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
______________________________**_________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/**mailman/listinfo/psdr_hamwan.**org<http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org>
Clever ;) What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad. The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20. --Bart On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116 <http://44.24.240.0/116>
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 <tel:44.24.240.0%20%2F%2020>
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Unless I've misunderstood the point of this network all together, there shouldn't be a case where we want the entire network address space to be reachable from the global internet. It's much more likely that the network will remain as autonomous as possible and any connections to the internet will be for connecting specific services through a gateway of some sort. A subnet of at least /23 (typical minimum for global BGP announcements) should be reserved for the purpose of being globally routable in the future, if/when HamWAN decides to peer with one or more ISPs. An address in the /23 can be given to each service gateway for connecting to the internet. The rest of the 44-net allocation can be treated as private address space, except that it's essentially guaranteed not to cause conflicts with the user-level networks since it's still globally unique. On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me@bartk.us> wrote:
Clever ;)
What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad.
The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20.
--Bart
On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Global reachability is not in conflict with autonomy. Achieving both simultaneously just requires careful design of HamWAN network services. If the HamWAN internet feed drops off, the routing, DNS and other services need to continue working. The first word in ASN is Autonomous after all. :) I consider NAT and Proxies as old crusty hacks from the age of ISPs giving out just 1 IP/customer. It's time to put these ideas to rest. IPv6 will do this on the commercial internet in the coming years, and AMPRnet will allow us to do it immediately here. For the cases where communication is to be restricted due to user preference, we can push filtering rules to firewalls at the edges of the network, and at the HamWAN <-> user site interface. In short, firewalls: yes, nat+gateways: no. If a user wants to make a service running on one of his servers public, he just needs to push an ACL update to HamWAN and it'll be opened up. No need to re-IP, update DNS, change NICs, whatever else. And most importantly, it makes everyone equal. Your subnet allocation has the same powers as mine. There is no special ground to fight over, such as space on a public subnet, or access to some officially sanctioned gateway servers that are allowed to do special things. If you want though, you can of course live in the world of private IPs and NAT. Just configure your LAN router that way. Complete freedom of configuration. This is the way the internet should have evolved for geeks! --Bart On 2/13/2013 8:30 AM, Cory (NQ1E) wrote:
Unless I've misunderstood the point of this network all together, there shouldn't be a case where we want the entire network address space to be reachable from the global internet. It's much more likely that the network will remain as autonomous as possible and any connections to the internet will be for connecting specific services through a gateway of some sort.
A subnet of at least /23 (typical minimum for global BGP announcements) should be reserved for the purpose of being globally routable in the future, if/when HamWAN decides to peer with one or more ISPs. An address in the /23 can be given to each service gateway for connecting to the internet.
The rest of the 44-net allocation can be treated as private address space, except that it's essentially guaranteed not to cause conflicts with the user-level networks since it's still globally unique.
On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Clever ;)
What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad.
The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20.
--Bart
On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116 <http://44.24.240.0/116>
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 <tel:44.24.240.0%20%2F%2020>
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
Just saw this, "just needs to push an ACL update". Why can't we just route all traffic and let the client nodes run their own firewalls? We *really* don't want to be in the distributed firewall business. :) On Wed, Feb 13, 2013 at 4:04 PM, Bart Kus <me@bartk.us> wrote:
Global reachability is not in conflict with autonomy. Achieving both simultaneously just requires careful design of HamWAN network services. If the HamWAN internet feed drops off, the routing, DNS and other services need to continue working. The first word in ASN is Autonomous after all. :)
I consider NAT and Proxies as old crusty hacks from the age of ISPs giving out just 1 IP/customer. It's time to put these ideas to rest. IPv6 will do this on the commercial internet in the coming years, and AMPRnet will allow us to do it immediately here. For the cases where communication is to be restricted due to user preference, we can push filtering rules to firewalls at the edges of the network, and at the HamWAN <-> user site interface. In short, firewalls: yes, nat+gateways: no.
If a user wants to make a service running on one of his servers public, he just needs to push an ACL update to HamWAN and it'll be opened up. No need to re-IP, update DNS, change NICs, whatever else. And most importantly, it makes everyone equal. Your subnet allocation has the same powers as mine. There is no special ground to fight over, such as space on a public subnet, or access to some officially sanctioned gateway servers that are allowed to do special things.
If you want though, you can of course live in the world of private IPs and NAT. Just configure your LAN router that way.
Complete freedom of configuration. This is the way the internet should have evolved for geeks!
--Bart
On 2/13/2013 8:30 AM, Cory (NQ1E) wrote:
Unless I've misunderstood the point of this network all together, there shouldn't be a case where we want the entire network address space to be reachable from the global internet. It's much more likely that the network will remain as autonomous as possible and any connections to the internet will be for connecting specific services through a gateway of some sort.
A subnet of at least /23 (typical minimum for global BGP announcements) should be reserved for the purpose of being globally routable in the future, if/when HamWAN decides to peer with one or more ISPs. An address in the /23 can be given to each service gateway for connecting to the internet.
The rest of the 44-net allocation can be treated as private address space, except that it's essentially guaranteed not to cause conflicts with the user-level networks since it's still globally unique.
On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me@bartk.us> wrote:
Clever ;)
What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad.
The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20.
--Bart
On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 <44.24.240.0%20%2F%2020>
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
It's just a little more efficient to stop unwanted traffic early, before it takes up a bunch of airtime. Just an optimization, which may not be worth the complexity right up front. Your suggestion works too. --Bart On 2/19/2013 8:46 PM, Benjamin Krueger wrote:
Just saw this, "just needs to push an ACL update". Why can't we just route all traffic and let the client nodes run their own firewalls? We *really* don't want to be in the distributed firewall business. :)
On Wed, Feb 13, 2013 at 4:04 PM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Global reachability is not in conflict with autonomy. Achieving both simultaneously just requires careful design of HamWAN network services. If the HamWAN internet feed drops off, the routing, DNS and other services need to continue working. The first word in ASN is Autonomous after all. :)
I consider NAT and Proxies as old crusty hacks from the age of ISPs giving out just 1 IP/customer. It's time to put these ideas to rest. IPv6 will do this on the commercial internet in the coming years, and AMPRnet will allow us to do it immediately here. For the cases where communication is to be restricted due to user preference, we can push filtering rules to firewalls at the edges of the network, and at the HamWAN <-> user site interface. In short, firewalls: yes, nat+gateways: no.
If a user wants to make a service running on one of his servers public, he just needs to push an ACL update to HamWAN and it'll be opened up. No need to re-IP, update DNS, change NICs, whatever else. And most importantly, it makes everyone equal. Your subnet allocation has the same powers as mine. There is no special ground to fight over, such as space on a public subnet, or access to some officially sanctioned gateway servers that are allowed to do special things.
If you want though, you can of course live in the world of private IPs and NAT. Just configure your LAN router that way.
Complete freedom of configuration. This is the way the internet should have evolved for geeks!
--Bart
On 2/13/2013 8:30 AM, Cory (NQ1E) wrote:
Unless I've misunderstood the point of this network all together, there shouldn't be a case where we want the entire network address space to be reachable from the global internet. It's much more likely that the network will remain as autonomous as possible and any connections to the internet will be for connecting specific services through a gateway of some sort.
A subnet of at least /23 (typical minimum for global BGP announcements) should be reserved for the purpose of being globally routable in the future, if/when HamWAN decides to peer with one or more ISPs. An address in the /23 can be given to each service gateway for connecting to the internet.
The rest of the 44-net allocation can be treated as private address space, except that it's essentially guaranteed not to cause conflicts with the user-level networks since it's still globally unique.
On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Clever ;)
What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad.
The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20.
--Bart
On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116 <http://44.24.240.0/116>
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 <tel:44.24.240.0%20%2F%2020>
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
It's not just optimization. We have serious restrictions on what type of content can be moved over our RF links. Everyone who runs a device that transmits is responsible for its operation. Luckily there is precedent here since each node can be considered the same as a "digital packet repeater" in historical context. In those cases, the repeater operator is not held liable for illegal content relayed through them as long as they take "reasonable measures" to limit it and when discovered, stop it. While it's not preferable to get into the distributed firewall business, it may be necessary if this network carries traffic to or from the internet. If we had another "reasonable" way to make sure only licensed hams were able to originate content on the network, firewalls likely wouldn't be needed. In a somewhat related issue, there is also precedent for hams using encrypted WiFi links with part 97 rules. Supposedly, it's only acceptable to encrypt when the purpose is not to hide the content of your message. This means that it's okay to run encryption as long you publish the decryption keys so that they could be found by the public (negating the point of using encryption in most cases). The frequencies that we're allowed to use as licensed radio amateurs belong to the public and we're allowed to use them for the purposes of experimentation and communication with other amateurs. In order to assure the fair use of such a valuable resource, we have to follow strict rules that prevent commercial interests from taking over. That's why we're not allowed to conduct business on the air or communicate with the general public (broadcast). That's also why it's important that anything transmitted is not intentionally obfuscated from anyone else's ability to view it. As a long-time computer engineer with a strong emphasis on security, the idea of having such an open network is very scary to me. However, it's also why I'm excited about the challenge. When most people think about security, they only think about secrecy (hiding your messages). However, security also includes authentication (making sure messages really come from the intended sender) and integrity (has this message been altered in transit). With those two aspects and a lot of help from public key cryptography, my hope is to contribute to making a network that is both open *and* secure. I've already made some strides in this area for other ham-related projects of mine, and now I'm hoping to translate that to the needs of the overall network. On Wed, Feb 20, 2013 at 12:16 AM, Bart Kus <me@bartk.us> wrote:
It's just a little more efficient to stop unwanted traffic early, before it takes up a bunch of airtime. Just an optimization, which may not be worth the complexity right up front. Your suggestion works too.
--Bart
On 2/19/2013 8:46 PM, Benjamin Krueger wrote:
Just saw this, "just needs to push an ACL update". Why can't we just route all traffic and let the client nodes run their own firewalls? We *really* don't want to be in the distributed firewall business. :)
On Wed, Feb 13, 2013 at 4:04 PM, Bart Kus <me@bartk.us> wrote:
Global reachability is not in conflict with autonomy. Achieving both simultaneously just requires careful design of HamWAN network services. If the HamWAN internet feed drops off, the routing, DNS and other services need to continue working. The first word in ASN is Autonomous after all. :)
I consider NAT and Proxies as old crusty hacks from the age of ISPs giving out just 1 IP/customer. It's time to put these ideas to rest. IPv6 will do this on the commercial internet in the coming years, and AMPRnet will allow us to do it immediately here. For the cases where communication is to be restricted due to user preference, we can push filtering rules to firewalls at the edges of the network, and at the HamWAN <-> user site interface. In short, firewalls: yes, nat+gateways: no.
If a user wants to make a service running on one of his servers public, he just needs to push an ACL update to HamWAN and it'll be opened up. No need to re-IP, update DNS, change NICs, whatever else. And most importantly, it makes everyone equal. Your subnet allocation has the same powers as mine. There is no special ground to fight over, such as space on a public subnet, or access to some officially sanctioned gateway servers that are allowed to do special things.
If you want though, you can of course live in the world of private IPs and NAT. Just configure your LAN router that way.
Complete freedom of configuration. This is the way the internet should have evolved for geeks!
--Bart
On 2/13/2013 8:30 AM, Cory (NQ1E) wrote:
Unless I've misunderstood the point of this network all together, there shouldn't be a case where we want the entire network address space to be reachable from the global internet. It's much more likely that the network will remain as autonomous as possible and any connections to the internet will be for connecting specific services through a gateway of some sort.
A subnet of at least /23 (typical minimum for global BGP announcements) should be reserved for the purpose of being globally routable in the future, if/when HamWAN decides to peer with one or more ISPs. An address in the /23 can be given to each service gateway for connecting to the internet.
The rest of the 44-net allocation can be treated as private address space, except that it's essentially guaranteed not to cause conflicts with the user-level networks since it's still globally unique.
On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me@bartk.us> wrote:
Clever ;)
What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad.
The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20.
--Bart
On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 <44.24.240.0%20%2F%2020>
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
First of all, +1, Informative. On 2/20/2013 11:22 AM, Cory (NQ1E) wrote:
It's not just optimization. We have serious restrictions on what type of content can be moved over our RF links. Everyone who runs a device that transmits is responsible for its operation. Luckily there is precedent here since each node can be considered the same as a "digital packet repeater" in historical context. In those cases, the repeater operator is not held liable for illegal content relayed through them as long as they take "reasonable measures" to limit it and when discovered, stop it.
While it's not preferable to get into the distributed firewall business, it may be necessary if this network carries traffic to or from the internet. If we had another "reasonable" way to make sure only licensed hams were able to originate content on the network, firewalls likely wouldn't be needed.
I think of the case of an audio repeater phone patch. A ham can call someone via hammy spectrum, but the return voice traffic may not belong to a ham. This has been allowed in the past as fair use. Now if we tweak the scenario and say the phone call is originally inbound from the repeater to the ham by a non-ham, but consists of content which the ham (in control of hanging up) considers appropriate as per the hammy rules of airwave content, should the conversation be allowed to continue? :) My read on this is yes. 99% of the airtime will be the bidirectional content of the conversation, just as it is in the outbound case. As long as this content is in compliance with ham law, it ought not matter who sent the original ring. The next step in this line of thinking is to translate the concepts of the analog telephone call to that of opening a digital inbound TCP session to a ham server. It's up to the ham who is hosting the server to ensure that the content of such conversations complies with ham rules. Hang up (TCP RST) the session if the content goes outside the law. The role of HamWAN is simply to facilitate the exchange of signals, and we're not held responsible (as per voice repeater rules) should hams decide to break the rules of content. There is of course that little lingering issue of the initial unsolicited ring in the analog world, or TCP SYN in the digital world making its way onto hammy spectrum. I like to think HamWAN could even set some useful precedent here, by delivering worthy use-cases, and perhaps cause an eventual tweak to the official rules to allow for short control messages ("I would like to talk") to be sent over hammy spectrum by non-hammies. Another way of thinking about this inbound ring from non-hams is that while the actual ring is received by ham equipment (repeater / digital microwave router) on a non-hammy medium (telco / ISP network), the hammy RF spectrum transmission from the repeater or digital microwave router is not a signal relay, but rather a whole new communication, initiated by a ham-licensed station (the repeater and its owner) to inform the target ham of the presence of an inbound message on the non-hammy medium, and is therefore ham2ham traffic after all! We can do these legal mental gymnastics for a long time, but the bottom line is unless someone actually complains and the FCC decides to care, we should just go on and operate instead of shying away in fear. If the practices are eventually ruled as illegal, we can cease such operations easily by applying new firewall rules. I hope it does not come to that as it would greatly stall the progress of digital ham radio.
In a somewhat related issue, there is also precedent for hams using encrypted WiFi links with part 97 rules. Supposedly, it's only acceptable to encrypt when the purpose is not to hide the content of your message. This means that it's okay to run encryption as long you publish the decryption keys so that they could be found by the public (negating the point of using encryption in most cases).
Agreed, and I know of people who do this with P25 gear. But I don't see any useful cases in which HamWAN could make use of encryption while publishing the keys.
The frequencies that we're allowed to use as licensed radio amateurs belong to the public and we're allowed to use them for the purposes of experimentation and communication with other amateurs. In order to assure the fair use of such a valuable resource, we have to follow strict rules that prevent commercial interests from taking over. That's why we're not allowed to conduct business on the air or communicate with the general public (broadcast). That's also why it's important that anything transmitted is not intentionally obfuscated from anyone else's ability to view it.
I see the definition of broadcast <http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=ad552c047464dd8e611924492c5b41c6&rgn=div5&view=text&node=47:5.0.1.1.6&idno=47#47:5.0.1.1.6.1.157.2> you cite there, and boy is that a weird one. I'd counter this with my phone patch example, and cite the ARRL guidance <http://www.arrl.org/phone-patch-guidelines> on the matter, which allow communication with non-amateur third parties (is that the same as "general public"?). In fact, the ARRL guidance counters what has been said about commercial communications in a previous thread: Calls to place an order for a commercial product may be made such as the proverbial call to the pizza restaurant to order food, but not calls to one's office to receive or to leave business messages since communications on behalf of ones employer are not permitted. The ARRL guidance on reverse autopatch (inbound TCP) actually runs counter to my views on the subject. In part, it states: Incoming calls to an autopatch must be answered and screened off the air by the control operator to ensure rule compliance. If an incoming call automatically causes the repeater to transmit, even if it's just a signal tone or notification message, then it is possible for an unlicensed person to initiate a transmission without the control operator's knowledge or approval, which is not permitted. This to me sounds like we absolutely need a ham-controlled edge firewall mechanism to "screen the calls off the air" as per the individual hams' specifications. One thing is for sure: we're in brand new territory. We need to tread with the utmost character so we set a good example for others who follow us.
As a long-time computer engineer with a strong emphasis on security, the idea of having such an open network is very scary to me. However, it's also why I'm excited about the challenge. When most people think about security, they only think about secrecy (hiding your messages). However, security also includes authentication (making sure messages really come from the intended sender) and integrity (has this message been altered in transit). With those two aspects and a lot of help from public key cryptography, my hope is to contribute to making a network that is both open *and* secure.
I've already made some strides in this area for other ham-related projects of mine, and now I'm hoping to translate that to the needs of the overall network.
This is exactly right. Well, almost. :) Cisco's thinking gets it right when they refer to AAA: Authentication, Authorization and Accounting. For anyone unfamiliar with what these concepts mean exactly, can refer to this page <http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html#wp1000889>. Also Wikipedia has a page on AAA <http://en.wikipedia.org/wiki/AAA_protocol>. The additional point you make about Integrity may not necessarily fall under the "Authentication" concept, since that deals more with actors in a network rather than the non-molestation of their messages, but can be served nicely by an implementation of IPSec in AH mode <http://en.wikipedia.org/wiki/Ipsec#Authentication_Header>. Tons of work here for sure, after the lower layers of the network (RF) are up and running. --Bart
On Wed, Feb 20, 2013 at 12:16 AM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
It's just a little more efficient to stop unwanted traffic early, before it takes up a bunch of airtime. Just an optimization, which may not be worth the complexity right up front. Your suggestion works too.
--Bart
On 2/19/2013 8:46 PM, Benjamin Krueger wrote:
Just saw this, "just needs to push an ACL update". Why can't we just route all traffic and let the client nodes run their own firewalls? We *really* don't want to be in the distributed firewall business. :)
On Wed, Feb 13, 2013 at 4:04 PM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Global reachability is not in conflict with autonomy. Achieving both simultaneously just requires careful design of HamWAN network services. If the HamWAN internet feed drops off, the routing, DNS and other services need to continue working. The first word in ASN is Autonomous after all. :)
I consider NAT and Proxies as old crusty hacks from the age of ISPs giving out just 1 IP/customer. It's time to put these ideas to rest. IPv6 will do this on the commercial internet in the coming years, and AMPRnet will allow us to do it immediately here. For the cases where communication is to be restricted due to user preference, we can push filtering rules to firewalls at the edges of the network, and at the HamWAN <-> user site interface. In short, firewalls: yes, nat+gateways: no.
If a user wants to make a service running on one of his servers public, he just needs to push an ACL update to HamWAN and it'll be opened up. No need to re-IP, update DNS, change NICs, whatever else. And most importantly, it makes everyone equal. Your subnet allocation has the same powers as mine. There is no special ground to fight over, such as space on a public subnet, or access to some officially sanctioned gateway servers that are allowed to do special things.
If you want though, you can of course live in the world of private IPs and NAT. Just configure your LAN router that way.
Complete freedom of configuration. This is the way the internet should have evolved for geeks!
--Bart
On 2/13/2013 8:30 AM, Cory (NQ1E) wrote:
Unless I've misunderstood the point of this network all together, there shouldn't be a case where we want the entire network address space to be reachable from the global internet. It's much more likely that the network will remain as autonomous as possible and any connections to the internet will be for connecting specific services through a gateway of some sort.
A subnet of at least /23 (typical minimum for global BGP announcements) should be reserved for the purpose of being globally routable in the future, if/when HamWAN decides to peer with one or more ISPs. An address in the /23 can be given to each service gateway for connecting to the internet.
The rest of the 44-net allocation can be treated as private address space, except that it's essentially guaranteed not to cause conflicts with the user-level networks since it's still globally unique.
On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Clever ;)
What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad.
The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20.
--Bart
On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116 <http://44.24.240.0/116>
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us <mailto:me@bartk.us>> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 <tel:44.24.240.0%20%2F%2020>
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
It appears that we're getting our layers mixed up. Phone patches to the pizza place are legitimate because the patching system itself is run by a licensed control operator. In this case, the RF link is layer 1 and the phone call is at least layer 3. The rules are for governing who gets to use layer 1 and for what purpose. It would be totally inappropriate for a pizza place to get a radio and camp on a frequency for the purpose of accepting orders. However, contacting another ham and asking them to order a pizza for you on their phone (or giving you an auto patch to do it yourself) is appropriate because the RF portion is still ham-to-ham, even if the message being relayed is not. The same goes for "broadcasting". Your transmission must be intended for one or more hams, even if the message must be relayed by them to reach its final destination. If you knew the general public all had scanners tuned to a ham frequency, it would not be appropriate to create your own radio show meant for them. Regarding AAA, I think we were also thinking about different layers. Securing the configuration of a network device and providing "security" for a network service (think SSL/TLS) is quite a bit different. I was referring to the latter. Using IPSec(AH) is a very good idea. I have high hopes that this will all work out. It sounds like so much fun, I can't contain myself! ;) -Cory On Wed, Feb 20, 2013 at 9:55 PM, Bart Kus <me@bartk.us> wrote:
First of all, +1, Informative.
On 2/20/2013 11:22 AM, Cory (NQ1E) wrote:
It's not just optimization. We have serious restrictions on what type of content can be moved over our RF links. Everyone who runs a device that transmits is responsible for its operation. Luckily there is precedent here since each node can be considered the same as a "digital packet repeater" in historical context. In those cases, the repeater operator is not held liable for illegal content relayed through them as long as they take "reasonable measures" to limit it and when discovered, stop it.
While it's not preferable to get into the distributed firewall business, it may be necessary if this network carries traffic to or from the internet. If we had another "reasonable" way to make sure only licensed hams were able to originate content on the network, firewalls likely wouldn't be needed.
I think of the case of an audio repeater phone patch. A ham can call someone via hammy spectrum, but the return voice traffic may not belong to a ham. This has been allowed in the past as fair use.
Now if we tweak the scenario and say the phone call is originally inbound from the repeater to the ham by a non-ham, but consists of content which the ham (in control of hanging up) considers appropriate as per the hammy rules of airwave content, should the conversation be allowed to continue? :) My read on this is yes. 99% of the airtime will be the bidirectional content of the conversation, just as it is in the outbound case. As long as this content is in compliance with ham law, it ought not matter who sent the original ring.
The next step in this line of thinking is to translate the concepts of the analog telephone call to that of opening a digital inbound TCP session to a ham server. It's up to the ham who is hosting the server to ensure that the content of such conversations complies with ham rules. Hang up (TCP RST) the session if the content goes outside the law. The role of HamWAN is simply to facilitate the exchange of signals, and we're not held responsible (as per voice repeater rules) should hams decide to break the rules of content.
There is of course that little lingering issue of the initial unsolicited ring in the analog world, or TCP SYN in the digital world making its way onto hammy spectrum. I like to think HamWAN could even set some useful precedent here, by delivering worthy use-cases, and perhaps cause an eventual tweak to the official rules to allow for short control messages ("I would like to talk") to be sent over hammy spectrum by non-hammies.
Another way of thinking about this inbound ring from non-hams is that while the actual ring is received by ham equipment (repeater / digital microwave router) on a non-hammy medium (telco / ISP network), the hammy RF spectrum transmission from the repeater or digital microwave router is not a signal relay, but rather a whole new communication, initiated by a ham-licensed station (the repeater and its owner) to inform the target ham of the presence of an inbound message on the non-hammy medium, and is therefore ham2ham traffic after all!
We can do these legal mental gymnastics for a long time, but the bottom line is unless someone actually complains and the FCC decides to care, we should just go on and operate instead of shying away in fear. If the practices are eventually ruled as illegal, we can cease such operations easily by applying new firewall rules. I hope it does not come to that as it would greatly stall the progress of digital ham radio.
In a somewhat related issue, there is also precedent for hams using encrypted WiFi links with part 97 rules. Supposedly, it's only acceptable to encrypt when the purpose is not to hide the content of your message. This means that it's okay to run encryption as long you publish the decryption keys so that they could be found by the public (negating the point of using encryption in most cases).
Agreed, and I know of people who do this with P25 gear. But I don't see any useful cases in which HamWAN could make use of encryption while publishing the keys.
The frequencies that we're allowed to use as licensed radio amateurs belong to the public and we're allowed to use them for the purposes of experimentation and communication with other amateurs. In order to assure the fair use of such a valuable resource, we have to follow strict rules that prevent commercial interests from taking over. That's why we're not allowed to conduct business on the air or communicate with the general public (broadcast). That's also why it's important that anything transmitted is not intentionally obfuscated from anyone else's ability to view it.
I see the definition of broadcast<http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=ad552c047464dd8e611924492c5b41c6&rgn=div5&view=text&node=47:5.0.1.1.6&idno=47#47:5.0.1.1.6.1.157.2>you cite there, and boy is that a weird one. I'd counter this with my phone patch example, and cite the ARRL guidance<http://www.arrl.org/phone-patch-guidelines>on the matter, which allow communication with non-amateur third parties (is that the same as "general public"?). In fact, the ARRL guidance counters what has been said about commercial communications in a previous thread:
Calls to place an order for a commercial product may be made such as the proverbial call to the pizza restaurant to order food, but not calls to one's office to receive or to leave business messages since communications on behalf of ones employer are not permitted.
The ARRL guidance on reverse autopatch (inbound TCP) actually runs counter to my views on the subject. In part, it states:
Incoming calls to an autopatch must be answered and screened off the air by the control operator to ensure rule compliance. If an incoming call automatically causes the repeater to transmit, even if it's just a signal tone or notification message, then it is possible for an unlicensed person to initiate a transmission without the control operator's knowledge or approval, which is not permitted.
This to me sounds like we absolutely need a ham-controlled edge firewall mechanism to "screen the calls off the air" as per the individual hams' specifications.
One thing is for sure: we're in brand new territory. We need to tread with the utmost character so we set a good example for others who follow us.
As a long-time computer engineer with a strong emphasis on security, the idea of having such an open network is very scary to me. However, it's also why I'm excited about the challenge. When most people think about security, they only think about secrecy (hiding your messages). However, security also includes authentication (making sure messages really come from the intended sender) and integrity (has this message been altered in transit). With those two aspects and a lot of help from public key cryptography, my hope is to contribute to making a network that is both open *and* secure.
I've already made some strides in this area for other ham-related projects of mine, and now I'm hoping to translate that to the needs of the overall network.
This is exactly right. Well, almost. :) Cisco's thinking gets it right when they refer to AAA: Authentication, Authorization and Accounting. For anyone unfamiliar with what these concepts mean exactly, can refer to this page<http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html#wp1000889>. Also Wikipedia has a page on AAA<http://en.wikipedia.org/wiki/AAA_protocol>. The additional point you make about Integrity may not necessarily fall under the "Authentication" concept, since that deals more with actors in a network rather than the non-molestation of their messages, but can be served nicely by an implementation of IPSec in AH mode<http://en.wikipedia.org/wiki/Ipsec#Authentication_Header> .
Tons of work here for sure, after the lower layers of the network (RF) are up and running.
--Bart
On Wed, Feb 20, 2013 at 12:16 AM, Bart Kus <me@bartk.us> wrote:
It's just a little more efficient to stop unwanted traffic early, before it takes up a bunch of airtime. Just an optimization, which may not be worth the complexity right up front. Your suggestion works too.
--Bart
On 2/19/2013 8:46 PM, Benjamin Krueger wrote:
Just saw this, "just needs to push an ACL update". Why can't we just route all traffic and let the client nodes run their own firewalls? We *really* don't want to be in the distributed firewall business. :)
On Wed, Feb 13, 2013 at 4:04 PM, Bart Kus <me@bartk.us> wrote:
Global reachability is not in conflict with autonomy. Achieving both simultaneously just requires careful design of HamWAN network services. If the HamWAN internet feed drops off, the routing, DNS and other services need to continue working. The first word in ASN is Autonomous after all. :)
I consider NAT and Proxies as old crusty hacks from the age of ISPs giving out just 1 IP/customer. It's time to put these ideas to rest. IPv6 will do this on the commercial internet in the coming years, and AMPRnet will allow us to do it immediately here. For the cases where communication is to be restricted due to user preference, we can push filtering rules to firewalls at the edges of the network, and at the HamWAN <-> user site interface. In short, firewalls: yes, nat+gateways: no.
If a user wants to make a service running on one of his servers public, he just needs to push an ACL update to HamWAN and it'll be opened up. No need to re-IP, update DNS, change NICs, whatever else. And most importantly, it makes everyone equal. Your subnet allocation has the same powers as mine. There is no special ground to fight over, such as space on a public subnet, or access to some officially sanctioned gateway servers that are allowed to do special things.
If you want though, you can of course live in the world of private IPs and NAT. Just configure your LAN router that way.
Complete freedom of configuration. This is the way the internet should have evolved for geeks!
--Bart
On 2/13/2013 8:30 AM, Cory (NQ1E) wrote:
Unless I've misunderstood the point of this network all together, there shouldn't be a case where we want the entire network address space to be reachable from the global internet. It's much more likely that the network will remain as autonomous as possible and any connections to the internet will be for connecting specific services through a gateway of some sort.
A subnet of at least /23 (typical minimum for global BGP announcements) should be reserved for the purpose of being globally routable in the future, if/when HamWAN decides to peer with one or more ISPs. An address in the /23 can be given to each service gateway for connecting to the internet.
The rest of the 44-net allocation can be treated as private address space, except that it's essentially guaranteed not to cause conflicts with the user-level networks since it's still globally unique.
On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me@bartk.us> wrote:
Clever ;)
What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad.
The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20.
--Bart
On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 <44.24.240.0%20%2F%2020>
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
We really need to think long and hard about whether it's a good idea to connect this network to the internet. I am still unconvinced of the value of this proposition, and it causes a great many extremely difficult technical and legal challenges. If nothing else, it is a distraction for us today. If we really want to explore that feature of the network, we should do it in a future phase after the network is already established. In the meantime, we can block traditionally encrypted ports on the network as standard practice; no need for one-off changes from end-users. On Wed, Feb 20, 2013 at 11:38 PM, Cory (NQ1E) <cory@nq1e.hm> wrote:
It appears that we're getting our layers mixed up.
Phone patches to the pizza place are legitimate because the patching system itself is run by a licensed control operator. In this case, the RF link is layer 1 and the phone call is at least layer 3. The rules are for governing who gets to use layer 1 and for what purpose. It would be totally inappropriate for a pizza place to get a radio and camp on a frequency for the purpose of accepting orders. However, contacting another ham and asking them to order a pizza for you on their phone (or giving you an auto patch to do it yourself) is appropriate because the RF portion is still ham-to-ham, even if the message being relayed is not.
The same goes for "broadcasting". Your transmission must be intended for one or more hams, even if the message must be relayed by them to reach its final destination. If you knew the general public all had scanners tuned to a ham frequency, it would not be appropriate to create your own radio show meant for them.
Regarding AAA, I think we were also thinking about different layers. Securing the configuration of a network device and providing "security" for a network service (think SSL/TLS) is quite a bit different. I was referring to the latter.
Using IPSec(AH) is a very good idea.
I have high hopes that this will all work out. It sounds like so much fun, I can't contain myself! ;)
-Cory
On Wed, Feb 20, 2013 at 9:55 PM, Bart Kus <me@bartk.us> wrote:
First of all, +1, Informative.
On 2/20/2013 11:22 AM, Cory (NQ1E) wrote:
It's not just optimization. We have serious restrictions on what type of content can be moved over our RF links. Everyone who runs a device that transmits is responsible for its operation. Luckily there is precedent here since each node can be considered the same as a "digital packet repeater" in historical context. In those cases, the repeater operator is not held liable for illegal content relayed through them as long as they take "reasonable measures" to limit it and when discovered, stop it.
While it's not preferable to get into the distributed firewall business, it may be necessary if this network carries traffic to or from the internet. If we had another "reasonable" way to make sure only licensed hams were able to originate content on the network, firewalls likely wouldn't be needed.
I think of the case of an audio repeater phone patch. A ham can call someone via hammy spectrum, but the return voice traffic may not belong to a ham. This has been allowed in the past as fair use.
Now if we tweak the scenario and say the phone call is originally inbound from the repeater to the ham by a non-ham, but consists of content which the ham (in control of hanging up) considers appropriate as per the hammy rules of airwave content, should the conversation be allowed to continue? :) My read on this is yes. 99% of the airtime will be the bidirectional content of the conversation, just as it is in the outbound case. As long as this content is in compliance with ham law, it ought not matter who sent the original ring.
The next step in this line of thinking is to translate the concepts of the analog telephone call to that of opening a digital inbound TCP session to a ham server. It's up to the ham who is hosting the server to ensure that the content of such conversations complies with ham rules. Hang up (TCP RST) the session if the content goes outside the law. The role of HamWAN is simply to facilitate the exchange of signals, and we're not held responsible (as per voice repeater rules) should hams decide to break the rules of content.
There is of course that little lingering issue of the initial unsolicited ring in the analog world, or TCP SYN in the digital world making its way onto hammy spectrum. I like to think HamWAN could even set some useful precedent here, by delivering worthy use-cases, and perhaps cause an eventual tweak to the official rules to allow for short control messages ("I would like to talk") to be sent over hammy spectrum by non-hammies.
Another way of thinking about this inbound ring from non-hams is that while the actual ring is received by ham equipment (repeater / digital microwave router) on a non-hammy medium (telco / ISP network), the hammy RF spectrum transmission from the repeater or digital microwave router is not a signal relay, but rather a whole new communication, initiated by a ham-licensed station (the repeater and its owner) to inform the target ham of the presence of an inbound message on the non-hammy medium, and is therefore ham2ham traffic after all!
We can do these legal mental gymnastics for a long time, but the bottom line is unless someone actually complains and the FCC decides to care, we should just go on and operate instead of shying away in fear. If the practices are eventually ruled as illegal, we can cease such operations easily by applying new firewall rules. I hope it does not come to that as it would greatly stall the progress of digital ham radio.
In a somewhat related issue, there is also precedent for hams using encrypted WiFi links with part 97 rules. Supposedly, it's only acceptable to encrypt when the purpose is not to hide the content of your message. This means that it's okay to run encryption as long you publish the decryption keys so that they could be found by the public (negating the point of using encryption in most cases).
Agreed, and I know of people who do this with P25 gear. But I don't see any useful cases in which HamWAN could make use of encryption while publishing the keys.
The frequencies that we're allowed to use as licensed radio amateurs belong to the public and we're allowed to use them for the purposes of experimentation and communication with other amateurs. In order to assure the fair use of such a valuable resource, we have to follow strict rules that prevent commercial interests from taking over. That's why we're not allowed to conduct business on the air or communicate with the general public (broadcast). That's also why it's important that anything transmitted is not intentionally obfuscated from anyone else's ability to view it.
I see the definition of broadcast<http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=ad552c047464dd8e611924492c5b41c6&rgn=div5&view=text&node=47:5.0.1.1.6&idno=47#47:5.0.1.1.6.1.157.2>you cite there, and boy is that a weird one. I'd counter this with my phone patch example, and cite the ARRL guidance<http://www.arrl.org/phone-patch-guidelines>on the matter, which allow communication with non-amateur third parties (is that the same as "general public"?). In fact, the ARRL guidance counters what has been said about commercial communications in a previous thread:
Calls to place an order for a commercial product may be made such as the proverbial call to the pizza restaurant to order food, but not calls to one's office to receive or to leave business messages since communications on behalf of ones employer are not permitted.
The ARRL guidance on reverse autopatch (inbound TCP) actually runs counter to my views on the subject. In part, it states:
Incoming calls to an autopatch must be answered and screened off the air by the control operator to ensure rule compliance. If an incoming call automatically causes the repeater to transmit, even if it's just a signal tone or notification message, then it is possible for an unlicensed person to initiate a transmission without the control operator's knowledge or approval, which is not permitted.
This to me sounds like we absolutely need a ham-controlled edge firewall mechanism to "screen the calls off the air" as per the individual hams' specifications.
One thing is for sure: we're in brand new territory. We need to tread with the utmost character so we set a good example for others who follow us.
As a long-time computer engineer with a strong emphasis on security, the idea of having such an open network is very scary to me. However, it's also why I'm excited about the challenge. When most people think about security, they only think about secrecy (hiding your messages). However, security also includes authentication (making sure messages really come from the intended sender) and integrity (has this message been altered in transit). With those two aspects and a lot of help from public key cryptography, my hope is to contribute to making a network that is both open *and* secure.
I've already made some strides in this area for other ham-related projects of mine, and now I'm hoping to translate that to the needs of the overall network.
This is exactly right. Well, almost. :) Cisco's thinking gets it right when they refer to AAA: Authentication, Authorization and Accounting. For anyone unfamiliar with what these concepts mean exactly, can refer to this page<http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfaaa.html#wp1000889>. Also Wikipedia has a page on AAA<http://en.wikipedia.org/wiki/AAA_protocol>. The additional point you make about Integrity may not necessarily fall under the "Authentication" concept, since that deals more with actors in a network rather than the non-molestation of their messages, but can be served nicely by an implementation of IPSec in AH mode<http://en.wikipedia.org/wiki/Ipsec#Authentication_Header> .
Tons of work here for sure, after the lower layers of the network (RF) are up and running.
--Bart
On Wed, Feb 20, 2013 at 12:16 AM, Bart Kus <me@bartk.us> wrote:
It's just a little more efficient to stop unwanted traffic early, before it takes up a bunch of airtime. Just an optimization, which may not be worth the complexity right up front. Your suggestion works too.
--Bart
On 2/19/2013 8:46 PM, Benjamin Krueger wrote:
Just saw this, "just needs to push an ACL update". Why can't we just route all traffic and let the client nodes run their own firewalls? We *really* don't want to be in the distributed firewall business. :)
On Wed, Feb 13, 2013 at 4:04 PM, Bart Kus <me@bartk.us> wrote:
Global reachability is not in conflict with autonomy. Achieving both simultaneously just requires careful design of HamWAN network services. If the HamWAN internet feed drops off, the routing, DNS and other services need to continue working. The first word in ASN is Autonomous after all. :)
I consider NAT and Proxies as old crusty hacks from the age of ISPs giving out just 1 IP/customer. It's time to put these ideas to rest. IPv6 will do this on the commercial internet in the coming years, and AMPRnet will allow us to do it immediately here. For the cases where communication is to be restricted due to user preference, we can push filtering rules to firewalls at the edges of the network, and at the HamWAN <-> user site interface. In short, firewalls: yes, nat+gateways: no.
If a user wants to make a service running on one of his servers public, he just needs to push an ACL update to HamWAN and it'll be opened up. No need to re-IP, update DNS, change NICs, whatever else. And most importantly, it makes everyone equal. Your subnet allocation has the same powers as mine. There is no special ground to fight over, such as space on a public subnet, or access to some officially sanctioned gateway servers that are allowed to do special things.
If you want though, you can of course live in the world of private IPs and NAT. Just configure your LAN router that way.
Complete freedom of configuration. This is the way the internet should have evolved for geeks!
--Bart
On 2/13/2013 8:30 AM, Cory (NQ1E) wrote:
Unless I've misunderstood the point of this network all together, there shouldn't be a case where we want the entire network address space to be reachable from the global internet. It's much more likely that the network will remain as autonomous as possible and any connections to the internet will be for connecting specific services through a gateway of some sort.
A subnet of at least /23 (typical minimum for global BGP announcements) should be reserved for the purpose of being globally routable in the future, if/when HamWAN decides to peer with one or more ISPs. An address in the /23 can be given to each service gateway for connecting to the internet.
The rest of the 44-net allocation can be treated as private address space, except that it's essentially guaranteed not to cause conflicts with the user-level networks since it's still globally unique.
On Wed, Feb 13, 2013 at 2:28 AM, Bart Kus <me@bartk.us> wrote:
Clever ;)
What if HamWAN switches ISPs? All that IPv6 space would need to be given up. It can't follow you AFAIK. Or the ISP may charge whatever they feel like to let you take it with you. Also bad.
The fees for IPv6 are not as low as I had hoped, but not as high as you think either! There's a 25% discount in effect for "extra-small" allocations (which are still larger than the entire IPv4 internet). The cost looks to be $937.50/yr. Not sure it's worth the cost, given the IPv4 AMPRnet situation. We can very likely just expand our AMPRnet allocation if we out-grow the /20.
--Bart
On 2/13/2013 1:10 AM, Cory (NQ1E) wrote:
Here's an IPv6 allocation for you ;)
::ffff:44.24.240.0/116
With the obvious exception of AMPRNet addresses for amateur radio use, IP allocations should come from an ISP. Obtaining a direct allocation from ARIN would cost around a couple grand per year.
On Wed, Feb 13, 2013 at 12:46 AM, Bart Kus <me@bartk.us> wrote:
Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 <44.24.240.0%20%2F%2020>
https://portal.ampr.org/networks.php?a=region&id=191
HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :)
What an incredibly productive day,
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing listPSDR@hamwan.orghttp://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/21/2013 05:05 PM, Benjamin Krueger wrote:
We really need to think long and hard about whether it's a good idea to connect this network to the internet. I am still unconvinced of the value of this proposition, and it causes a great many extremely difficult technical and legal challenges.
In the US, unless the account you have with a broadband ISP specifically permits connection sharing (especially public connection sharing), they may threaten to kill your access unless you take the gateway to the mesh network down. They may also decide to drop you as a customer entirely and be done with you. Additionally, there are several states that have laws against doing just this. Community wireless networks run into this problem a lot and not a few have been shut down here. It was a common complaint from USian projects at the last International Summit for Community Wireless Networks (this link was referenced a lot during the "State of wireless" roundtable discussion: http://www.cybertelecom.org/broadband/muni.htm).
If nothing else, it is a distraction for us today. If we really want to explore that feature of the network, we should do it in a future phase after the network is already established. In the meantime, we can block
That would be a good strategy. In addition, you will want to have a large community of active users to help you make a case for not being shut down if it comes to it.
traditionally encrypted ports on the network as standard practice; no need for one-off changes from end-users.
The problem there is that you will then be forcing users to connect to online services insecurely. Passive attackers will be able to easily record authentication credentials to webmail services (which are increasingly being used as authentication providers by other services - - Google Mail comes to mind immediately), banks, and other sites. You might be incurring additional liability if you set that policy. You might also want to reconsider setting up network gateways for this reason. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "I'm prophetic, not infallible." --Mr. Morden -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEn7T0ACgkQO9j/K4B7F8GNJQCeJSnodhgNVAo0OG+UUs4Dhj4z Q6EAoKoHM9VH2aPdOkFW6LWPIl35y1Zt =R4B0 -----END PGP SIGNATURE-----
Lets be super clear here. We're not building a general use ISP. It's an experimental open network. We'll provide the best integrity controls we can, but there are no promises and every participant should know exactly what they're getting in to. On Fri, Feb 22, 2013 at 2:12 PM, The Doctor <drwho@virtadpt.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/21/2013 05:05 PM, Benjamin Krueger wrote:
We really need to think long and hard about whether it's a good idea to connect this network to the internet. I am still unconvinced of the value of this proposition, and it causes a great many extremely difficult technical and legal challenges.
In the US, unless the account you have with a broadband ISP specifically permits connection sharing (especially public connection sharing), they may threaten to kill your access unless you take the gateway to the mesh network down. They may also decide to drop you as a customer entirely and be done with you.
Additionally, there are several states that have laws against doing just this. Community wireless networks run into this problem a lot and not a few have been shut down here. It was a common complaint from USian projects at the last International Summit for Community Wireless Networks (this link was referenced a lot during the "State of wireless" roundtable discussion: http://www.cybertelecom.org/broadband/muni.htm).
If nothing else, it is a distraction for us today. If we really want to explore that feature of the network, we should do it in a future phase after the network is already established. In the meantime, we can block
That would be a good strategy. In addition, you will want to have a large community of active users to help you make a case for not being shut down if it comes to it.
traditionally encrypted ports on the network as standard practice; no need for one-off changes from end-users.
The problem there is that you will then be forcing users to connect to online services insecurely. Passive attackers will be able to easily record authentication credentials to webmail services (which are increasingly being used as authentication providers by other services - - Google Mail comes to mind immediately), banks, and other sites.
You might be incurring additional liability if you set that policy. You might also want to reconsider setting up network gateways for this reason.
- -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/
PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/
"I'm prophetic, not infallible." --Mr. Morden
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlEn7T0ACgkQO9j/K4B7F8GNJQCeJSnodhgNVAo0OG+UUs4Dhj4z Q6EAoKoHM9VH2aPdOkFW6LWPIl35y1Zt =R4B0 -----END PGP SIGNATURE-----
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
Hello, "The Doctor"! Do you have a The Name? :) I do remember reading about Byzantium when I was doing initial research for HamWAN, so welcome to the mailing list! You make an interesting, but scary point about laws banning public networks. I'm not so much worried about ISP policies; ISPs can be changed. I've surfed through the link you provided and while it makes claims that laws have been passed, I can't seem to find any direct link to state legislature legal websites which publish the ratified laws. Worryingly, it seems Washington state is affected. Are you able to find anything official on the books for WA you can point us to? The short blurb of laws cited at the top of this page <http://www.cybertelecom.org/states/wa.htm> only seems to require that any public network give explicit authorization to the general public for connections. This seems like a reasonable policy and should not kill intentional public networks. In our case, we're not an open public network, and do require user registrations. Since we're using spectrum reserved for hams, we just have to make sure each user is a ham. It's not hard to become a ham, either. So we're just 1 step removed from being fully open to the general public. :) The laws on the main page look to be concerned with local GOVERNMENTS offering free networks and stomping out free enterprise competition. This also seems reasonable to me. I'd rather get my free WiFi from an NPO than a government. Let the government donate to an NPO if they want to setup such things in their community. Let the berating of my opinions begin! :) --Bart On 02/22/2013 02:20 PM, Benjamin Krueger wrote:
Lets be super clear here. We're not building a general use ISP. It's an experimental open network. We'll provide the best integrity controls we can, but there are no promises and every participant should know exactly what they're getting in to.
On Fri, Feb 22, 2013 at 2:12 PM, The Doctor <drwho@virtadpt.net <mailto:drwho@virtadpt.net>> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/21/2013 05:05 PM, Benjamin Krueger wrote: > We really need to think long and hard about whether it's a good > idea to connect this network to the internet. I am still > unconvinced of the value of this proposition, and it causes a great > many extremely difficult technical and legal challenges.
In the US, unless the account you have with a broadband ISP specifically permits connection sharing (especially public connection sharing), they may threaten to kill your access unless you take the gateway to the mesh network down. They may also decide to drop you as a customer entirely and be done with you.
Additionally, there are several states that have laws against doing just this. Community wireless networks run into this problem a lot and not a few have been shut down here. It was a common complaint from USian projects at the last International Summit for Community Wireless Networks (this link was referenced a lot during the "State of wireless" roundtable discussion: http://www.cybertelecom.org/broadband/muni.htm).
> If nothing else, it is a distraction for us today. If we really > want to explore that feature of the network, we should do it in a > future phase after the network is already established. In the > meantime, we can block
That would be a good strategy. In addition, you will want to have a large community of active users to help you make a case for not being shut down if it comes to it.
> traditionally encrypted ports on the network as standard practice; > no need for one-off changes from end-users.
The problem there is that you will then be forcing users to connect to online services insecurely. Passive attackers will be able to easily record authentication credentials to webmail services (which are increasingly being used as authentication providers by other services - - Google Mail comes to mind immediately), banks, and other sites.
You might be incurring additional liability if you set that policy. You might also want to reconsider setting up network gateways for this reason.
- -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/
PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/
"I'm prophetic, not infallible." --Mr. Morden
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlEn7T0ACgkQO9j/K4B7F8GNJQCeJSnodhgNVAo0OG+UUs4Dhj4z Q6EAoKoHM9VH2aPdOkFW6LWPIl35y1Zt =R4B0 -----END PGP SIGNATURE-----
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-- Benjamin
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/22/2013 07:46 PM, Bart Kus wrote:
Hello, "The Doctor"! Do you have a The Name? :) I do remember reading
If you like, call me Bryce. Most everybody else does.
about Byzantium when I was doing initial research for HamWAN, so welcome to the mailing list!
Thank you very much.
You make an interesting, but scary point about laws banning public networks. I'm not so much worried about ISP policies; ISPs can be
Not necessarily, due to existing non-competition laws. Telecom companies tend to have limited monopoly rights in certain areas (such as Comcast being the only cable company in an area, or all broadband links being owned by Covad, which other broadband providers have to rent from to rebrand). For example, in Washington, DC (where I live) there are regions of the city where broadband isn't possible because the non-competition laws don't permit any of the usual suspects build out the infrastructure because they'd be stepping on the toes of the other telecom companies. Columbia Heights is one such area, meaning that HacDC is limited to cellular access and the T-1 that our landlord negotiated from someone for a scary price. There are no plans to extend FiOS or even ADSL into this area because everybody's lawyers will cry foul - we've tried. And don't get me started on the municial fibre network which nobody but the government of DC is allowed to connect to (not even the public schools). For more information on that, please contact the New America Foundation (newamerica.net) because they are the subject matter experts in wireless policy these days.
changed. I've surfed through the link you provided and while it makes claims that laws have been passed, I can't seem to find any direct link to state legislature legal websites which publish the ratified laws.
§ 54.16.330, "(b) For the provision of wholesale telecommunications services within the district and by contract with another public utility district. Nothing in this subsection shall be construed to authorize public utility districts to provide telecommunications services to end users." Also, this bit from section 2: "Rates, terms, and conditions are discriminatory or preferential when a public utility district offering rates, terms, and conditions to an entity for wholesale telecommunications services does not offer substantially similar rates, terms, and conditions to all other entities seeking substantially similar services." In other words, municipal projects that compete with existing LECs can't actually compete with the LECs.
The short blurb of laws cited at the top of this page <http://www.cybertelecom.org/states/wa.htm> only seems to require that any public network give explicit authorization to the general public for connections. This seems like a reasonable policy and should not kill intentional public networks. In our case, we're not an open public
Except for the bit where it also can't compete directly with existing providers, who have limited monopoly rights. If they see it as a threat they'll close it down. If you like, I can contact some legal experts who are involved in this aspect of community wireless, I'm on the engineering side. I speak Babel better than legalese. :)
network, and do require user registrations. Since we're using spectrum reserved for hams, we just have to make sure each user is a ham. It's not hard to become a ham, either. So we're just 1 step removed from being fully open to the general public. :)
In that regard, I think you should be fine. It would be hard for an ISP to claim that you're trying to cause trouble in a non-compete area.
The laws on the main page look to be concerned with local GOVERNMENTS offering free networks and stomping out free enterprise competition.
Not just governments; the project in Portland, OR got shut down, in part, due to legal pressure from Verizon and Comcast out there. It also didn't help the project that got killed in Pittsburgh back in '01. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "'PC LOAD LETTER'?! What the /[a-z]{4}/ does that mean??" --Michael Bolton, _Office Space_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEpeTwACgkQO9j/K4B7F8HipACg5MNcif4MRENTJBqDENGkrJVj azcAn1bOGRMU0VodTJhHB/9eyKuYSnaD =Dt96 -----END PGP SIGNATURE-----
Junior is growing up quickly <g>. -----Original Message----- From: PSDR [mailto:psdr-bounces@hamwan.org] On Behalf Of Bart Kus Sent: Wednesday, February 13, 2013 12:46 AM To: Puget Sound Data Ring Subject: [HamWAN PSDR] Holy smokes, we have Internet address space! Result: APPROVED Your allocated subnet is: 44.24.240.0 / 20 https://portal.ampr.org/networks.php?a=region&id=191 HamWAN now has 4096 real Internet IPs to play with. Next up: we gotta crack the mystery of getting IPv6 net space. Any volunteers? :) What an incredibly productive day, --Bart _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
participants (5)
-
Bart Kus -
Benjamin Krueger -
Cory (NQ1E) -
Rob Salsgiver -
The Doctor