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,


- Lynwood
KB3VWG


On Wednesday, November 30, 2022 at 10:13:36 AM EST, Marius Petrescu via 44net <44net@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@mailman.ampr.org>
Date: Wednesday, November 30, 2022 at 4:56 AM
To: 44net@mailman.ampr.org <44net@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@mailman.ampr.org
To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________
44net mailing list -- 44net@mailman.ampr.org
To unsubscribe send an email to 44net-leave@mailman.ampr.org