Hey Scott,
Like Marius noted, that's not what the portal does.
Although, as he also noted - if you're in ARRL-MDC section, I'll design such a
connection for your allocation and forward it in whole via the other mechanism/interface.
If in my grid square, we'll try HSMM, lol.
To be clear, you only have Native IPv6 access to the Internet?
What VPN or encapsulation protocols are you configured to receive currently?
All,
Is the test IP space still in our AMPRNet-owned block?
I can test something with him (Wireguard is what I'm ready for - I currently forward
the DNS and HTTP IPs in my allocation to an AWS server via native IPv6 in this manner). I
don't think I can IPENCAP to you via IPv6...but we'll try.
73,
- LynwoodKB3VWG
On Wednesday, November 30, 2022 at 10:13:36 AM EST, Marius Petrescu via 44net
<44net(a)mailman.ampr.org> wrote:
This has actually nothing to do with the portal. The portal manages the IPV4 allocations
and tunnel and gateway interconnections.
How an user connects to an upstream gateway is out of the scope of the portal. Now if this
specific gateway offers 4 in 6, IPIP, Open VPN or whatever other tunnel options, that is
exclusively the decision and responsibility of the gateway owner/operator (in this case
the gateway Rob talks about).
This is exactly the concept of Point of Presence: These PoPs should offer user
connectivity by what ever means they ant or are able to, while being themselves gateways
providing connectivity to the rest of the AMPR network by any means available and
possible. This would take the burden of full interconnections from the end users with
their individual gateways to the PoP operators, offering other well supported connectivity
to their users (subnets or individual).
These connectivity solutions can not be fully managed by the portal, and should not be.
How end users connect to a gateway providing AMPR network access is neither uniform, nor
standardized, and outside of the scope of the AMPR central gateway. Any such decisions
would impose limits instead of connectivity freedom, and would contradict the very
foundation of what ham radio should be about: experimentation, progress, originality and
technical freedom.
Please do not downgrade the ARDC to a IP space and grant supplier.
Marius, YO2LOJ
On 30/11/2022 16:54, Scott Gillins via 44net wrote:
Awesome I did not see any documentation to that extent or config options for it in the
portal. Can you please point me in the right direction.
Scott
From: Rob PE1CHL via 44net <44net(a)mailman.ampr.org>
Date: Wednesday, November 30, 2022 at 4:56 AM
To: 44net(a)mailman.ampr.org <44net(a)mailman.ampr.org>
Subject: [44net] Re: 4 in 6 tunnel support
We do offer that on our gateway. There is only one user (were 3 before), but still...
I agree that there is some use case for it, e.g. with provider routers that have trouble
with GRE over NAT.
Rob
On 11/29/22 20:56, Scott Gillins via 44net wrote:
I was wondering if you had considered looking at a 4 in 6 tunnel support. I know that it
may seem backwards with a lot of things moving to native v6 but the 44 net is a great
resource for hams. One example of why I can see needing this is a lot of providers,
specifically wireless, are doing a double or triple NAT of their own ipv4 address space.
While this is OK for most internet activities it is not good to support inbound
connections. You do however get a native IPV6 address that is not nated and fully
routable. Having a headend location to support a 4 in 6 tunnel would help a lot of folks.
I do support large networks as part of my day job and would be willing to help set up and
support if you wanted to take this on.
Thanks,
Scott
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org