29 Apr
2013
29 Apr
'13
5:25 p.m.
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<http://en.wikipedia.org/wiki/Private_network>rk>.
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
translation<http://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
29 Apr
29 Apr
5:54 p.m.
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
30 Apr
30 Apr
2:54 a.m.
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
--
Jann Traschewski, Lenbachstr. 6, D-90489 Nuernberg, Germany
Tel.: +49-911-696971, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
4:09 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRf3w1AAoJEHFIN1T8ZA8vFR8QAK1lRNpPkfnp4PZJIOTwHLQR
MVoC8uk46H8mXtlzsS9wroPt/R8yF0i631TIvKaUskC2dPPw1mVT2LBmCGPlx/y1
bGIFdrcx+UsK+d7wUbG1WBBvoU3N08Fnq34oOGZ1fXd87WRT1OXJzmnzFTboArcg
fLmK0NegrxMxWagvo94HKztgzUHje9gcRlcia9l013a4SQQEhjM8HgI9kDVifb6Y
TkThEV5TgLGFkk6cz+2R8n0EC+WvCjVoFIK+29nFegsKSL3nrdtjnVzO7d7sudY4
yTQIsrooj2RF5/dDiIWKMoopVBCC+/2Z16gLsrn8KbxoqcxM8UEN7VUrGrRVIznz
sBiRbjy2WvUZ0eQEUia9tLxP5XaG8RJa/FUZGuqE6FHHQnSA/Tj+db+3z+IHYxIn
PIHvktYr1fMB0PGTfZHXcIXhN33K1OKtjUQDS0fserTlsS0xDcpE4cW8xLfOygGR
fqQtGDtvjHNVRSKYjBhEBaUrgDLAQGxY4e15bdUljsftJKoMaI/cfQvaS5FQDyIe
9iVo+grTToQv6V9iJeV1281auM4cN8cGckzhreAs/Bb9xR5HjUKwZ8vgfkBqO8o+
h/aWGINs0PMrLvKlU8RFB/GZhBTdn3DrC0H8l0Q5XEMkCYxylzoWvm34X/xsFkEY
zZ/AbsXxBaWtQhdEVRVj
=JleC
-----END PGP SIGNATURE-----
6:04 a.m.
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. 
8:42 a.m.
On 2013-04-30 08:27:23 -0400, Jim Alles <kb3tbx(a)gmail.com>
wrote in <CABS3LnJ7KE4DwUJpZzYk=DjDOXgNCtw8CojDO969AbLkWg5fvg(a)mail.gmail.com>om>:
(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
10:08 a.m.
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
1 May
1 May
5:59 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRgOdzAAoJEHFIN1T8ZA8vJxgP+gNrUy9Immry0WJt6yrYrJq4
2MgXL+u0U0oOAcTOO4bwAiUvNZUJ7wOBf9srog6zyvhGIKF23D/VhG38FxaJHAbr
5Z3HBIvAS828+q/Gf2qzWcCN6ZGReozrg79S4ryTEc4K0FrqoI2MNihBoeg7C5T7
dkrqPEb7/7+ymM1ZX6mME3iqmkULVW3WCus9gY1SC0iG+FaBGGfT6P+jUdoS2JrF
Tleo71mNl5fxyD2ldJ179Pq724PwRhZOeeO5T6GXK/Iux3+XqP1WKeh6epGCEE9h
+8EI9eC9M2uyot9MwI+vWanLGkkugBz3Zz8icad+mgStRl6adDOvgDYKVhL0Bi0C
LVvk0NVE9AyZszj2fohLeLgTpDo1Rn1g7ZbEJwJ3xNIHwLsM3abXF/9ILsSfjF9T
SxTKxynCMboAdRjzP9rrQ+O3Pk7G3TmcLZBuW0tmwKebiD9yuI/i6C6g/lxlhjVu
+FZYxVC1fWFTsXqklaS/jRVIcdLaJgaHGuvbXC2nWPd2/iTsHJHgBvg/Mx+asGsr
Pkw/s83aVwvgcZEO/mekLtwPuFniVPG+PTAP0CBqE0HEZDuF/gqqvcqc1vnQADak
f7HK9I5PXJTmeMo8mR4n58Jt2kF6goQZxVNvsFBQYUz1RHWO78saOJS5TecSg0tZ
2HNRbYe8yg0pODE+aB0B
=ed0P
-----END PGP SIGNATURE-----
2:07 p.m.
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(a)windomeister.com
2:21 p.m.
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(a)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(a)windomeister.com
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html
29 Apr
29 Apr
6:41 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
9:13 p.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html
10:18 p.m.
On Mon, Apr 29, 2013 at 9:13 PM, Andrew Ragone <ajr9166(a)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
(PennREN<http://www.kinber.org/docs/PennREN_Construction_Complete_release…)
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.pdf>be relevant?
73,
Jim A. KB3TBX for PSARC <http://www.clubs.psu.edu/up/k3cr/>
10:39 p.m.
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(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Mon, Apr 29, 2013 at 9:13 PM, Andrew Ragone <ajr9166(a)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
(PennREN<http://www.kinber.org/docs/PennREN_Construction_Complete_release…)
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.pdf>be
relevant?
73,
Jim A. KB3TBX for PSARC <http://www.clubs.psu.edu/up/k3cr/>
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html
10:41 p.m.
...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(a)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(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Mon, Apr 29, 2013 at 9:13 PM, Andrew Ragone <ajr9166(a)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
(PennREN<http://www.kinber.org/docs/PennREN_Construction_Complete_release…)
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.pdf>be
relevant?
73,
Jim A. KB3TBX for PSARC <http://www.clubs.psu.edu/up/k3cr/>
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html
10:40 p.m.
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(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Mon, Apr 29, 2013 at 9:13 PM, Andrew Ragone <ajr9166(a)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
(PennREN<http://www.kinber.org/docs/PennREN_Construction_Complete_release…)
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.pdf>be
relevant?
73,
Jim A. KB3TBX for PSARC <http://www.clubs.psu.edu/up/k3cr/>
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html
11:37 p.m.
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
4222
days inactive
4224
days old
17 comments
9 participants
participants (9)
-
Andrew Ragone -
Brian Kantor -
C.J. Adams-Collier KF7BMP -
Eric Fort -
Geoff Joy -
Jann Traschewski -
Jim Alles -
Marc, LX1DUC -
Thomas Osterried