Lets concentrate on one aspect of this for a moment:
the big argument here and what the TAC proposal seems to address (their
approach nonwithstanding) seems to be seperating the address space used
for ham to ham only, vs Ham to Non-Ham.
First off, in order to be assigned addresses from the amprnet block per
the AUP do I not need to be an amateur radio licensee?
If my thinking is correct that in order to comply with the AUP and be
issued ip address space from the amprnet allocation I must first have my
amateur radio license then should not every ip address in the amprnet
blocks be by definition acceptable to communicate with? if not why not?
That covers HAM to HAM - NO RENUMBERING OR SPLITTING THE NETWORK
REQUIRED!
on the other hand, ham to general internet may have issues with local
regulatory issues and it may not. How that is handled is and should be
the choice of the local operator of the gateway between 44net rf links
and any non-rf links. Where we have the issue is putting non acceptable
traffic over an rf link. ultimately the source of the traffic has long
ago been identified as the responsible party. by virtue of the AUP we
ought be able to trust any address from amprnet space holding the
originator of said traffic responsible, or in the case of traffic
to/from or transiting amprnet space to another non amprnet ip space the
first station (which should have amprnet addressing on all RF
interfaces) to place the traffic onto an amateur RF segment (part 15 or
similar by country rf segments who cares, as that's allowed)Eric
AF6EP
On 2021-08-12 10:53, pete M via 44Net wrote:
Rob you say,
there is NO minimal subnet size on BGP! We use
BGP to route single
addresses (/32). The "minimal /24" restriction is only a policy on
Internet BGP, because there >already are so many routes in the table
and they do not want to have even more.
Totally true! the /24 minimal size is for get smaller routing table on
the internet routers. It is good practice on networking to inplement
such solution. And the TAC proposal is exactly that. splitting 2 /10
blocks (4,194,304 possible host for each /10 ) to have 2 simple network
that are easy to maintain. You probably know that already. Now lets
think about the future and not the past. We want more use of the 44
net. We want entry level to be easier, we want people to learn
networking, we want them to do it in a safe manner and we want them to
be able to interect just between them or between them and the rest of
the world.
Now imagine a new user that receive a /28 from one of our pop. He need
a router to manage his allocation and advertise it on the metwork he
will do it by iBGP and he will need to route the /28 on his side. He
will also need to know to who he want to connect and not. If he want to
connect to the whole routable internet there is no problem. He route
everything to the AMPR and all is good. But what if he want ham only on
his network. He make routing tables to the 12 millions possible 44 IP
adress we still have? How will he know that some of those IP are not
real ham or those address can have some endrypted packet and those will
end on the airwaves on his RF networks and put him in a very bad
situation toward his governing regulator.
However, on our own backbone network (which runs
BGP on private AS
numbers and is in no way exchanging BGP information with the internet,
only with other >AMPRnet routers over tunnels) we do not have to
implement that restriction and we can route everything.
And still, people can filter by subnet size on their own routers when
they want a smaller table and are not interested in all those detailed
routes.
Exactly people wont want to split route and program certain subnet and
do all that maintenance that need to be done if a new allocation is
given or other not fun task. They will want simple things to do and
they will want to have fun while learning.
You also say:
Given the current scale of the AMPRnet network we
should not worry
about the number of routes. When compared to internet, we are
miniscule.
We have 700 routes in the IPIP mesh, currently about 230 routes in the
Dutch network, I think about 2500 in the HAMNET network, etc.
All in all probably less than 10000. And you can always filter some
detailed routes when you are not handling specific cases like the
above.
(e.g. the whole world would not be interested in all our /32 routes
unless they want to handle /32 addresses connected to a PoP in TK)
Yes we are miniscule compared to the internet, and even less then a
speck of dust compared to the IPV6 address space. This does not mean
that we should not care about building a simple and stable network
where simpler user wont have to care about routing and checking their
config every few weeks to make sure they have all the lastest desirable
to them subnet as they will addon with time. Remember that there are
people thet DONT want to have route to and from the internet. How will
you provide them with a /28 and a stable and simple configuration if
they connect to your RF network that have route that goes and come from
everywhere? Firewall? Will the sysop of all the rf network will love to
have to deal with specific configuration on some of their node for user
X?
and then he decide that another node will work better for him, he turn
his antenna and everything need to be reconfigured.
Dual addressing of both the 44.0/10 and 44.128/10 on RF backbone and
the pop's will fix all this type of maintenance. Yes it will be a assle
to add the second route to your existing setup as a sysop. But as a
sysop you will not have to fiddle with every change users will want to
do. your config will be a little more complicated. But the whole
network will be a lot less difficult to manage.
Technically if the proposition would been accpeted you would not even
neet to renumber. You would need to dual route 2 subnet. The one you
already have that would become the intranet for ham only and a new
subnet that is open to the whole worls. You could have all the
configuration /ssh port of your deveice facing the hamonly portion of
the network and have no more russian/china/kiddy scanner harmering your
router for brut force access.
Then your user could choose to joint either of the 2 possibility or
even better both but in a very controled fashion and with a sens of
securit for the ham only side cause none of the non ham world would
have access. It is not a perfect system, but when you can remove 99% of
risk from a system it is a huge improvement. I do not say it will be
perfect and good security practice wont be needed. But we will start
with a very large leap.
I understand that you are not happy to have to change stuff in your
network. But can you be a little bit more open to change?
________________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
part de Rob PE1CHL via 44Net <44net(a)mailman.ampr.org>
Envoyé : 11 août 2021 10:54
À : 44net(a)mailman.ampr.org
Cc : Rob PE1CHL
Objet : Re: [44net] A new era of IPv4 Allocations : Agree
On 8/11/21 4:37 PM, Toussaint OTTAVI via 44Net wrote:
Le 11/08/2021 à 16:05, Rob PE1CHL via 44Net a écrit :
I think ARDC can offer end-user PoP access to their backbone
themselves, and regional groups can always decide to setup their own
access which connects to such a PoP and allows their own end-users to
connect.
But we may have a problem if we tie a specific user to a specific
subnet on the portal, and we want to provide him the same subnet
whatever the POP he uses. F/ex, if a Corsican user obtains an
allocation for Internet stuff (assume 44.190.11.0/30), and if he
connects to your POP in the Netherlands, how could we route the
incoming traffic to it ? As Internet eBGP minimal subnet is /24,
44.190.11.0/24 will still be announced via my POP. That means I'll have
to route the incoming traffic from my POP to yours, then to the user ?
When you have a system that you want to be capable of doing such special
routing, you need to have a BGP session with the backbone.
Over that BGP session you can send or receive those routes.
There is NO minimal subnet size on BGP! We use BGP to route single
addresses (/32). The "minimal /24" restriction is only a policy on
Internet BGP, because there already are so many routes in the table and
they do not want to have even more.
However, on our own backbone network (which runs BGP on private AS
numbers and is in no way exchanging BGP information with the internet,
only with other AMPRnet routers over tunnels) we do not have to
implement that restriction and we can route everything.
And still, people can filter by subnet size on their own routers when
they want a smaller table and are not interested in all those detailed
routes.
On our current design, subnets for users are allocated
by us locally,
and we have two local POPs, both announcing our subnet. Access routers
can connect to POP1 or POP2. That's easy because all is local. But if
we want to allow any user to connect to any POP and always get the same
IP/subnet, things may not be so easy...
In our network it already works. Whenever a user connects e.g. to
OpenVPN, the route to their address is distributed using BGP.
So you can be on radio in network 44.137.40.0/22 (on a WiFi access
point), then switch off your radio and connect to OpenVPN using a
certificate that issues you address 44.137.40.2, and you still get the
correct routing. All routers in the Dutch network route that single
address to the OpenVPN server instead of to the router serving
44.137.40.0/22.
For this to work also for the other users on that WiFi access point,
proxy-arp has to be enabled on those accesspoint networks.
Then, when another user ARPs for 44.137.40.2 the router will answer with
its own MAC address and route the traffic using that single-address
route.
Works just fine!
We also have this for IPIP and IPsec tunnels, routes obtained from
ampr-ripd are automatically redistributed in our radionetwork using BGP.
Some users
also may not think their local access point is reliable
enough and want to connect to an ARDC PoP or even more than one.
It should always be possible to have multiple options, we should not
wire the possibilities into the network design.
Human being is what it is, and I don't think this is specific to
amateur radio, HI :-) Thus, every user must be allowed to connect to
any POP of its choice (not necessarily the nearest). On a dynamic DHCP
pool, that's easy. But if we want to distribute the same subnet to an
access router whatever the POP, is it possible to do that automatically
at WW scale ? Does it make sense for a TK user to connect to a PE POP ?
The fact our Echolink clients often connect to VK proxies is definitely
not a good reason, HI :-)
Given the current scale of the AMPRnet network we
should not worry
about the number of routes. When compared to internet, we are
miniscule.
We have 700 routes in the IPIP mesh, currently about 230 routes in the
Dutch network, I think about 2500 in the HAMNET network, etc.
All in all probably less than 10000. And you can always filter some
detailed routes when you are not handling specific cases like the above.
(e.g. the whole world would not be interested in all our /32 routes
unless they want to handle /32 addresses connected to a PoP in TK)
Then, should we revert to something simpler, with
mandatory "primary"
and "secondary" POPs (based on geographic location, and with specific
configuration / agreement between POP operators) ?
For users that connect and setup a BGP session, there is no need to
configure what network they have. But there may be a need to configure
a BGP peer. Current RouterOS requires that, the next version does not
(so you can accept any incoming BGP session using a single config item).
With the current software it would be required to configure somewhere
(
portal.ampr.org of course!) on which PoP you want to connect, and you
would get some info in return (like the BGP AS# and the IP address of
the BGP software).
Rob
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net