from the wiki at http://en.wikipedia.org/wiki/AMPRNet:
*44.128.0.0/16*
*44.128.x.x is the testing subnet and consists of 65,536 (216) addresses. Much akin to 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16 or 192.168.0.0/16, this is an unroutable private IP blockhttp://en.wikipedia.org/wiki/Private_network. Connectivity to the rest of the network should be given through router gateways http://en.wikipedia.org/wiki/Gateway_(telecommunications) much as one would do with Network address translationhttp://en.wikipedia.org/wiki/Network_address_translation in any other private IP block.*
There is no attribution to that statement, and nothing I could find at AMPR.org
Is this the best way to address devices when doing NAT into a private network? Any issues?
Or are there advantages to requesting assigned numbers?
thanks & 73,
Jim Alles
On Mon, Apr 29, 2013 at 05:25:45PM -0400, Jim Alles wrote:
Is this the best way to address devices when doing NAT into a private network? Any issues?
I'll have to update that entry on the wiki for 44.128/16; its definition was originally as a test-only subnet. I don't know that it's used much for that anymore. It might be time to return it to general assignment like any other regional subnet.
In general, I feel its unwise to use addresses that appear to be world routable (eg, 44.anything) in the private netspace behind NATs and firewalls. The confusion that results when they inadvertently leak out just isn't worth it. There are designated private networks (RFC1918) that are a wiser choice for behind a NAT gateway.
- Brian
I'll have to update that entry on the wiki for 44.128/16; its definition was originally as a test-only subnet. I don't know that it's used much for that anymore.
Yes, it is widely used here for testing purpose. Even to get around some annoying 'bugs' like the need to assign an IP-address for every Linux AX.25 interface (only used for APRS and no IP). Moreover I often help other system operators by remote and don't want to think about which RFC1918 address space is locally used. I just use 44.128/16 and I'm sure it will not clash in any way with local requirements.
It might be time to return it to general assignment like any other regional subnet.
That might break connectivity. Everybody is aware that 44.128/16 is used for testing. We don't know how many people are using it right know. And we don't know how many people will use it in future since they are used to it but not recognizing the change of purpose.
I don't recommend to change things as long as we don't run out of addresses.
73 de 5H/DG8NGN, Jann
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 30/04/2013 08:54, Jann Traschewski wrote:
I don't recommend to change things as long as we don't run out of addresses.
It wouldn't hurt however to start by marking the test usage of 44.161.0.0/16 as deprecated so OMs can plan to migrate their configurations.
73 de Marc, LX1DUC
I don't recommend to change things as long as we don't run out of addresses.
It wouldn't hurt however to start by marking the test usage of 44.161.0.0/16 as deprecated so OMs can plan to migrate their configurations.
I guess you are talking about 44.128/16 rather than 44.161/16...
I don't agree on this. I don't want to migrate to RFC1918 addresses. I want to keep 44.128/16 for testing purpose.
73, Jann
On 2013-04-30 08:27:23 -0400, Jim Alles kb3tbx@gmail.com wrote in CABS3LnJ7KE4DwUJpZzYk=DjDOXgNCtw8CojDO969AbLkWg5fvg@mail.gmail.com:
(Please trim inclusions from previous messages) _______________________________________________
Could we request that this block be included in RFC1918?
Why should we offer parts of our netblock to the world? NO! ;)
I've not followed the full discussion (due to lack of time). Considering NAT-behind-NAT problems, you may find the following quite new assigned RFC/network useful: http://en.wikipedia.org/wiki/Carrier-grade_NAT
The scenario and the problems with carrier grade NAT are described quite beautiful in this article http://chrisgrundemann.com/index.php/2011/nat444-cgn-lsn-breaks/
The network is 100.64.0.0/10
I hope I hit the point. If not, sorry.
vy 73, - Thomas dl9sau
On Tue, Apr 30, 2013 at 08:27:23AM -0400, Jim Alles wrote:
Could we request that this block be included in RFC1918?
I think that would be impractical as well as unwise. To implement that would require that the software for millions of routers worldwide would have to change, and I just don't see that happening. - Brian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yes I absolutely meant 44.128.0.0/16!
These networks are already defined by the community as test networks:
192.0.2.0/24 RFC5737 198.51.100.0/24 RFC5737 203.0.113.0/24 RFC5737
For benchmarking purposes and tests you may use 198.18.0.0/15 RFC2544.
For those trying to avoid RFC1918 collisions you may look into all of these address spaces:
100.64.0.0/10 RFC6598 169.254.0.0/16 RFC3927 192.0.2.0/24 RFC5737 198.18.0.0/15 RFC2544 198.51.100.0/24 RFC5737 203.0.113.0/24 RFC5737
RFC6598, as already stated, is probably best suited as "private" address space between 2 colliding RFC1918 networks.
Note that Amazon uses 169.254.0.0/16 for the direct connect service.
73 de Marc, LX1DUC
On 30/04/2013 12:04, Jann Traschewski wrote:
(Please trim inclusions from previous messages) _______________________________________________ I guess you are talking about 44.128/16 rather than 44.161/16...
I don't agree on this. I don't want to migrate to RFC1918 addresses. I want to keep 44.128/16 for testing purpose.
73, Jann
I have to agree with Marc on this. There are plenty of test and RFC1918 addresses for private nets or nets behind NAT where it makes no sense to use 44.128/16 as a test or private space. Where normal firewall rules might catch a leak of an RFC1918 address, they wouldn't catch a leak of a 44.128/16 address.
If you need a 44-net block, just coordinate a subnet for it. Net 44 is sparsely populated and it probably always will be and while there might not be a pressing need to allocate 44.128/16 to "real" addresses I see no reason to reserve it for all time. Deprecate it now with the advisory to contact your coordinator for an assigned address space.
The entire 44/8 space is "experimental" by definition.
I completely agree.
Even if we did want to reserve 44.128/16 for testing, we shouldn't need to add it to an RFC. All we would need to do is write a match rule to drop it from the BGP advertisements to the Internet and just know internally that it's test. But still there is plenty of address space to experiment without needing to do this in my opinion.
On Wed, May 1, 2013 at 12:07 PM, Geoff Joy geoff@windowmeister.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ I have to agree with Marc on this. There are plenty of test and RFC1918 addresses for private nets or nets behind NAT where it makes no sense to use 44.128/16 as a test or private space. Where normal firewall rules might catch a leak of an RFC1918 address, they wouldn't catch a leak of a 44.128/16 address.
If you need a 44-net block, just coordinate a subnet for it. Net 44 is sparsely populated and it probably always will be and while there might not be a pressing need to allocate 44.128/16 to "real" addresses I see no reason to reserve it for all time. Deprecate it now with the advisory to contact your coordinator for an assigned address space.
The entire 44/8 space is "experimental" by definition.
Geoff Joy - ke6qh - AmprNet IP Address Coordinator for San Bernardino & Riverside Counties. geoff@windomeister.com
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
I've never seen anyone treat 44.128.0.0/16 like 1918 space in production routers. So don't assume that these addresses are unique on the internet unless you blackhole that route inbound from your wan link.
That said, I've used that address space sometimes when other machines want to manage all of rfc1918 space and I want private address space.
YMMV.
On Mon, 2013-04-29 at 17:25 -0400, Jim Alles wrote:
(Please trim inclusions from previous messages) _______________________________________________ from the wiki at http://en.wikipedia.org/wiki/AMPRNet:
44.128.0.0/16 44.128.x.x is the testing subnet and consists of 65,536 (216) addresses. Much akin to 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16 or 192.168.0.0/16, this is an unroutable private IP block. Connectivity to the rest of the network should be given through router gateways much as one would do with Network address translation in any other private IP block.
There is no attribution to that statement, and nothing I could find at AMPR.org
Is this the best way to address devices when doing NAT into a private network? Any issues?
Or are there advantages to requesting assigned numbers?
thanks & 73,
Jim Alles
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
Another comment, though there are always unique design cases, why would you want NAT with 44net addresses? There are so many addresses and the benefits to running native addressing across a network are unrivaled.
Sent from my iPhone
On Apr 29, 2013, at 4:42 PM, "C.J. Adams-Collier KF7BMP" cjac@colliertech.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ I've never seen anyone treat 44.128.0.0/16 like 1918 space in production routers. So don't assume that these addresses are unique on the internet unless you blackhole that route inbound from your wan link.
That said, I've used that address space sometimes when other machines want to manage all of rfc1918 space and I want private address space.
YMMV.
On Mon, 2013-04-29 at 17:25 -0400, Jim Alles wrote:
(Please trim inclusions from previous messages) _______________________________________________ from the wiki at http://en.wikipedia.org/wiki/AMPRNet:
44.128.0.0/16 44.128.x.x is the testing subnet and consists of 65,536 (216) addresses. Much akin to 10.0.0.0/8, 172.16.0.0/12, 169.254.0.0/16 or 192.168.0.0/16, this is an unroutable private IP block. Connectivity to the rest of the network should be given through router gateways much as one would do with Network address translation in any other private IP block.
There is no attribution to that statement, and nothing I could find at AMPR.org
Is this the best way to address devices when doing NAT into a private network? Any issues?
Or are there advantages to requesting assigned numbers?
thanks & 73,
Jim Alles
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Mon, Apr 29, 2013 at 9:13 PM, Andrew Ragone ajr9166@rit.edu wrote:
Another comment, though there are always unique design cases, why would you want NAT with 44net addresses? There are so many addresses and the benefits to running native addressing across a network are unrivaled.
I don't.
The problem is our internet access is through the University, Penn State ( 128.118.0.0/16) and I have not yet found a way around that. I have been told it would take an act of God. That doesn't bother me (since I have seen it before ;). One possibility may be KINBER http://www.kinber.org/'s new Pennsylvania Research & Education Network (PennRENhttp://www.kinber.org/docs/PennREN_Construction_Complete_release_final.pdf) based here in State College. And I am still exploring that.
I would appreciate any other ideas. I do not have a formal IT background. What is possible? could this N2N http://luca.ntop.org/n2n.pdfbe relevant?
73, Jim A. KB3TBX for PSARC http://www.clubs.psu.edu/up/k3cr/
Ah gotcha. Fortunately the IPIP tunnel should help you on this.
You don't have to worry about direct BGP advertisements from PSU for your 44-subnet. Effectively 44.0.0.0/8 is advertised to the internet by CALI and the routing tables at CA know what subnet to route through your IPIP tunnel. So, all traffic ultimately to/from your 44-net allocation hits the internet through CA
On Mon, Apr 29, 2013 at 8:18 PM, Jim Alles kb3tbx@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Mon, Apr 29, 2013 at 9:13 PM, Andrew Ragone ajr9166@rit.edu wrote:
Another comment, though there are always unique design cases, why would you want NAT with 44net addresses? There are so many addresses and the benefits to running native addressing across a network are unrivaled.
I don't.
The problem is our internet access is through the University, Penn State ( 128.118.0.0/16) and I have not yet found a way around that. I have been told it would take an act of God. That doesn't bother me (since I have seen it before ;). One possibility may be KINBER http://www.kinber.org/'s new Pennsylvania Research & Education Network (PennRENhttp://www.kinber.org/docs/PennREN_Construction_Complete_release_final.pdf) based here in State College. And I am still exploring that.
I would appreciate any other ideas. I do not have a formal IT background. What is possible? could this N2N http://luca.ntop.org/n2n.pdfbe relevant?
73, Jim A. KB3TBX for PSARC http://www.clubs.psu.edu/up/k3cr/
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
...didnt quite finish...
And so the IPIP tunnel is anchored to your router at its normal WAN IP (one of the 128.118.0.0/16 addrs). Thats what completes the circuit, if-you-will.
On Mon, Apr 29, 2013 at 8:39 PM, Andrew Ragone ajr9166@rit.edu wrote:
Ah gotcha. Fortunately the IPIP tunnel should help you on this.
You don't have to worry about direct BGP advertisements from PSU for your 44-subnet. Effectively 44.0.0.0/8 is advertised to the internet by CALI and the routing tables at CA know what subnet to route through your IPIP tunnel. So, all traffic ultimately to/from your 44-net allocation hits the internet through CA
On Mon, Apr 29, 2013 at 8:18 PM, Jim Alles kb3tbx@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Mon, Apr 29, 2013 at 9:13 PM, Andrew Ragone ajr9166@rit.edu wrote:
Another comment, though there are always unique design cases, why would you want NAT with 44net addresses? There are so many addresses and the benefits to running native addressing across a network are unrivaled.
I don't.
The problem is our internet access is through the University, Penn State ( 128.118.0.0/16) and I have not yet found a way around that. I have been told it would take an act of God. That doesn't bother me (since I have seen it before ;). One possibility may be KINBER http://www.kinber.org/'s new Pennsylvania Research & Education Network (PennRENhttp://www.kinber.org/docs/PennREN_Construction_Complete_release_final.pdf) based here in State College. And I am still exploring that.
I would appreciate any other ideas. I do not have a formal IT background. What is possible? could this N2N http://luca.ntop.org/n2n.pdfbe relevant?
73, Jim A. KB3TBX for PSARC http://www.clubs.psu.edu/up/k3cr/
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
What just may be possible here, and it's something I'd explore in your position (and I may be in your same position in the near future...) is having the it department/staff provide you with a single IP address through which all your 44net traffic is routed and that becomes the gateway address on their side of the network. they simply announce your netblock (min /24) out of their AS using BGP the same as any of their other netblocks and route all traffic headed to your net44 subnet to you. you then set up a router that you manage with one interface on their network at the assigned address, and one interface on your network, or possibly an interface for each subnet. heck, for that matter, they could probably just drop you one or more vlans from one of their routers and you could work from there. once setup it would be very little work for them, it would likely conserve a couple ip addresses precious to them, and you could go about use of net44. one thing I've always wanted to try was setting up a node where stations connected over the air with an ax.25 physical layer and configured their ip stack via dhcp. thus the node holds a pool of addresses that in turn get leased to users as they come and go. no need for end users to neer to sign up for address space that way.
Eric AF6EP
On Mon, Apr 29, 2013 at 7:18 PM, Jim Alles kb3tbx@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Mon, Apr 29, 2013 at 9:13 PM, Andrew Ragone ajr9166@rit.edu wrote:
Another comment, though there are always unique design cases, why would you want NAT with 44net addresses? There are so many addresses and the benefits to running native addressing across a network are unrivaled.
I don't.
The problem is our internet access is through the University, Penn State ( 128.118.0.0/16) and I have not yet found a way around that. I have been told it would take an act of God. That doesn't bother me (since I have seen it before ;). One possibility may be KINBER http://www.kinber.org/'s new Pennsylvania Research & Education Network (PennRENhttp://www.kinber.org/docs/PennREN_Construction_Complete_release_final.pdf) based here in State College. And I am still exploring that.
I would appreciate any other ideas. I do not have a formal IT background. What is possible? could this N2N http://luca.ntop.org/n2n.pdfbe relevant?
73, Jim A. KB3TBX for PSARC http://www.clubs.psu.edu/up/k3cr/
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Mon, Apr 29, 2013 at 10:18:35PM -0400, Jim Alles wrote:
The problem is our internet access is through the University, Penn State ( 128.118.0.0/16) and I have not yet found a way around that.
This is precisely the situation that our longstanding method of tunnel gateways is designed to overcome.
You do this by setting up a Linux host that is assigned a single PSU address, probably something that isn't too hard to do. You shouldn't need to have them open any holes in the firewall or ask for special treatment as long as the existing firewall allows IPIP (internet protocol #4) through, which most do because the firewall managers never thought to block it, and also because some VPN schemes used to use it.
The PSU folks don't have to do anything about network 44 routing or BGP or whatever.
You then get a subnet allocation from your regional AMPRNet IP address coordinator and register a gateway for that subnet (via the PSU address) on the portal. Voila', you now have a subnet of AMPRNet routed to your Linux host via IP-IP encapsulation, and through the technique of tunnel gatewaying that Linux host is now connected to the AMPRNet, albeit at a somewhat limited bandwidth.
By making use of the tunnel gateway routing info (either from the static table ("encap file") on the portal or via Rip44d) you will have mesh connectivity to the other tunnel gateways that are working much the same as yours.
You can run JNOS or other software on the Linux host to make it a ham router.
The exact configuration of tunnel interfaces and routing tables varies depending on which distribution of Linux you're using, but people here on the mailing list should be able to describe to you their configurations for whichever Linux you're using. Note that you don't have to use Linux, it's just the most common.
It doesn't take a full-on host system. I'm told that people have used a Raspberry PI box to do this, or you can use OpenWRT or other micro-routers.
If you go this way, it'd be really cool for you to write it up as a wiki article for our wiki.ampr.org site. - Brian
-
Andrew Ragone -
Brian Kantor -
C.J. Adams-Collier KF7BMP -
Eric Fort -
Geoff Joy -
Jann Traschewski -
Jim Alles -
Marc, LX1DUC -
Thomas Osterried