Hey Antonios/Everyone,
Sorry for the late response, just getting back from vacation and sorting
through email. Trying to put my two cents in for a few of the threads
that have been rolling around.
IMHO the TAC plan as presented is a non-starter. Anything that involves
significant re-ip is overly burdensome even with funding. Usually $$
isn't the issue here, it is time and motivation from independent network
owners usually operating on a volunteer basis. Also, if a re-ip isn't
mandatory, we'll never get to the nirvana state where you can use the
hard coded routes without being 100% compliant, we'll always have the
legacy ranges that stick around. This is a pretty fundamental re-design
of how addresses have been historically allocated which is a big
challenge as well.
I also fail to see the justification of reserving 44.64/10 with no
future purpose when it is already in use. I currently have space in this
range that would be orphaned. While it wouldn't be a significant deal
for me to re-ip, as you've seen from other posters it will be for some
and I fail to see the well defined purpose to sequester such a large space.
Re selling space, there is no reason to sell more space. ARDC has plenty
of funding assuming it is appropriately managed going forward. If
anything they have the opposite problem, make sure funding is
appropriately allocated and well spent.
Back to the proposal, do we really need to allocate a dedicated /10 for
unconnected purposes? How about finding a /16 or /15 not in use or with
limited use? Is there really that large of a defined need to have 4
million IPs reserved as unconnected?
For me, I appreciate the opportunity to provide feedback and this seems
to be a solution in need of a problem. I might be missing something but
I fail to see the justification for this radical of a change in your paper.
Re the future, from my perspective I am very interested in the new
TAC-proposed Global PoP infrastructure and portal that has been
proposed. I'd love to see more/better gateway options, different options
for connecting (including easy to use methods for "newbies", options for
those stuck behind carrier NAT aside from running their own BGP/POP, and
a better portal to manage the space and connection options. This is
where I’d be focusing a lot of my time.
IMHO the TAC should be focused on network stewardship, architecture,
policy, and community need. I may have missed it, but does the TAC have
a defined charter? It might make sense to get community feedback and
prioritization on the problems we are trying to solve.
I'd also like to see ARDC have a better focus on providing network POP
and hosting infrastructure that supports the amateur community. While
giving out grants is great, I could see growth on the operations side as
well to support better infrastructure. Especially with funding there is
no reason you couldn't staff a small infrastructure department to
support this.
Another focus would be security, IMHO from my perspective there is
little visibility in to what transverses the network and if the AUP is
being followed. The "maybe a DOS" event we had a few weeks ago is a good
example. At a minimum those type of incidents should be investigated and
a postmortem published (properly redacted if needed). Given the exposure
externally it'd probably be a good idea to have a formal incident
response process in place.
Re the endpoint and connection discussion, I do use a Pi3 as my IPIP
gateway using one interface and 802.1Q VLANs. I have it behind my
primary pfsense firewall and forward ipencap from external to it. My
notes on how I set up the pi are here:
http://k9mev.ampr.org/piconfig.txt
This works for me but requires a bit advanced understanding of linux and
networking, feedback is appreciated though if I did something improper
:). If you'd like to tackle something similar and need some help please
do reach out. Happy to discuss via email or set up a zoom call.
I think the Pi solution or a cheap Mikrotik are both valid solutions.
I'd like to see ARDC or the community provide better documentation on
different configs. There is a ton of documentation out there, I had to
experiment and borrowed from various documents and scripts to get mine
working properly. Maybe a few reference architectures would be helpful
and speed adoption or a pi or vm image.
If you made it this far I appreciate the read. I also very much
appreciate all the hard work the TAC, BOD, ARDC Staff, and Community
have put in. I recognize most are volunteers and appreciate the time and
diminished sanity contributed!
Thank You,
Mark - K9MEV
On 7/27/2021 5:31 PM, Antonios Chariton (daknob) via 44Net wrote:
Fellow radio amateurs, I am writing to you on behalf
of the ARDC TAC, which I represent.
Those of you that were on our Community Call last Saturday may remember that I promised
you we would share our first proposal with the community. A few days after that, I am
happy to send that to you for your review, feedback, comments, questions, and
information!
You can find our 5-page PDF here:
https://pdf.daknob.net/ardc/tac128.pdf
<https://pdf.daknob.net/ardc/tac128.pdf>
The title is "ARDC 44.128/10 Allocation Proposal” and it briefly explains what we
propose to do with the IPv4 space of ARDC. It is based on careful consideration, planning,
and actual research[1] performed on the IP network and the Portal allocations.
Since the TAC does not have any authority on the IP (or any other) resources of ARDC, and
we only have an advisory role, we end this document with a proposed resolution we intend
to submit soon to the ARDC Board of Directors, where we urge them to vote and approve some
key things required for us to be able to achieve what is described.
We believe that the TAC represents the community and the 44 Net users, so we created this
document and post it here in advance, with the purpose of being able to answer your
questions, collect your feedback, and hear from you. This is why we briefly explain the
situation in about 4 pages, and then we end with the resolution we want the ARDC Board of
Directors to approve.
I hope you like it, and I remain at your disposal for anything you may need.
Antonis
Links:
[1] -
https://blog.daknob.net/mapping-44net/
<https://blog.daknob.net/mapping-44net/>
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net