<div dir="ltr">I have Hyperoptic. They are superb.<div>They originally only worked with apartment blocks - I believe this is no longer so.</div><div>In our block they have a rack high up on a wall downstairs and every apartment has a CAT5 line run up to it.</div><div>I don't know exactly what is in the rack. Hyperoptic depend on BT fibre for the link to the internet, I don;t know where this terminates.</div><div><br></div><div>I have a fixed IPV4 address which costs me a fiver a month, and take their VOIP service wish is a darned sight cheaper than BT line rental.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 29 Aug 2022 at 21:24, Andy Smith via GLLUG <<a href="mailto:gllug@mailman.lug.org.uk">gllug@mailman.lug.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On Mon, Aug 29, 2022 at 03:08:08PM +0100, Chris Bell via GLLUG wrote:<br>
> On Monday, 29 August 2022 13:40:54 BST aidangcole--- via GLLUG wrote:<br>
> > Would using Headscale / Tailscale simply solve this without all the<br>
> > routing hassle and admin ?<br>
> <br>
> Sorry, not understood. I have had to use port forwarding over a single IPv4 <br>
> address together with careful firewalling to do anything.<br>
<br>
So, you are used to having a static IPv4 at home and using NAT to<br>
forward ports on that IP to application servers within your home<br>
network.<br>
<br>
e.g. if your globally routable IPv4 were 1.2.3.4 and your<br>
LAN was <a href="http://192.168.123.0/24" rel="noreferrer" target="_blank">192.168.123.0/24</a> maybe you NAT <a href="http://1.2.3.4:80" rel="noreferrer" target="_blank">1.2.3.4:80</a> to<br>
<a href="http://192.168.123.4:80" rel="noreferrer" target="_blank">192.168.123.4:80</a> so that the web server on 192.168.123.4 is<br>
reachable from the public Internet as <a href="http://1.2.3.4/" rel="noreferrer" target="_blank">http://1.2.3.4/</a>.<br>
<br>
You now get native IPv6 but the problem is that it's a dynamic /48<br>
of which the first /64 is automatically set up on your LAN, but you<br>
don't know which /48 it will be a part of and this can change at any<br>
time.<br>
<br>
First of all I want to reiterate that your goal is quite niche. Most<br>
people are not hosting things at home, and don't want to host things<br>
at home. The need for IPv6 connectivity is like the need for basic<br>
Internet connectivity. It's so they can consume content that's out<br>
on the Internet, not run a datacentre at home.<br>
<br>
So, your most sensible options in my opinion are:<br>
<br>
a) Rent a server with static IPv6 assignment and use that as your<br>
   front end, not the IPv4/IPv6 at your home<br>
<br>
   This server might be a VM which at the low end would only be a<br>
   few dollars a month. Or it might be in one of the popular clouds.<br>
   Not literally a bare metal server, though that would work too.<br>
<br>
   You would VPN to it from your home using something like<br>
   wireguard, either directly or with a helper like the already<br>
   mentioned tailscale which makes things very simple.<br>
<br>
   Your home plus an arbitrary number of other locations connect<br>
   to your server and it does not matter that your home has dynamic<br>
   IPs because your home identifies itself to the VPN server (and<br>
   vice versa) by certificates.<br>
<br>
   You carve out /64s from the IPv6 assignment on your server, for<br>
   example maybe you have:<br>
<br>
    2001:db8:1234::/48 - Hosting provider assignment to your server<br>
        2001:db8:1234:0::/64 - things on your server<br>
        2001:db8:1234:1::/64 - your home<br>
        2001:db8:1234:2::/64 - another site<br>
        2001:db8:1234:3::/64 - third site<br>
        .<br>
        .<br>
        2001:db8:1234:ffff::/64 - 65,536th site<br>
<br>
   So there's a scheme for up to 65,536 globally routable networks<br>
   under one IPv6 prefix with each underlying network being v4, v6,<br>
   static or dynamic, doesn't matter. You can do it right now. Each<br>
   end site can change provider and connectivity method any number<br>
   of times but its global v6 assignment remains the same as long as<br>
   you keep your server.<br>
<br>
   e.g. http://[2001:db8:1234:1::4]/ hits your server, packets go<br>
   down the VPN to your home, served off of the same machine as<br>
   192.168.123.4 (or whatever its ISP-supplied v6 address is, and<br>
   obviously it would usually be a DNS name not a bare IPv6 address<br>
   used in the browser).<br>
<br>
   Downside is a star topology with all the traffic going through<br>
   your server. A further consequence of that is that you would have<br>
   to take steps to ensure that the things at each site are usable<br>
   locally to the site even if your server is not reachable by them.<br>
   Obviously you don't want to be unable to control your heating and<br>
   lights or manage your CCTV just because your VM at Linode is<br>
   unreachable! This isn't an insurmountable problem, just one that<br>
   too few people think about.<br>
<br>
b) Wait until there's enough choice of connectivity provider that<br>
   you can pay extra for static IPv6 assignment at home<br>
<br>
   Downsides:<br>
    - Probably costs more than the VM<br>
    - May not be available at all<br>
    - Might be harder to reliably serve things from your home than<br>
      from a VM or bare metal server in a purpose built datacentre<br>
    - Renumber every time you change domestic ISP unless you become<br>
      a member of RIPE NCC (€1,400/year), be allocated a v6<br>
      network of your own and then find a broadband ISP that will<br>
      announce it for you (more expense, hard)¹.<br>
<br>
It's possible that things could have been different if IPv6 had<br>
gained traction before the whole world was put behind IPv4 NAT to<br>
conserve address space, but it wasn't, so statistically no one² is<br>
running globally routable home networks with real services on them.<br>
All the IoT stuff has been built with that in mind and it's extra<br>
effort to self-host.<br>
<br>
Cheers,<br>
Andy<br>
<br>
¹ It is also much easier and cheaper to find a VM provider that will<br>
  announce your own network(s) than it is to find a home broadband<br>
  supplier that will do the same.<br>
<br>
² Yes, I am, and I'm sure plenty of other people on this list are,<br>
  because that's our thing. But in terms of customer base for any<br>
  commercial product or service, it's not really a market. They<br>
  expect the consumer to use their centralised cloud-hosted web<br>
  interface, self-host in the cloud, or else self-host at home and<br>
  access via VPN.<br>
<br>
-- <br>
<a href="https://bitfolk.com/" rel="noreferrer" target="_blank">https://bitfolk.com/</a> -- No-nonsense VPS hosting<br>
<br>
-- <br>
GLLUG mailing list<br>
<a href="mailto:GLLUG@mailman.lug.org.uk" target="_blank">GLLUG@mailman.lug.org.uk</a><br>
<a href="https://mailman.lug.org.uk/mailman/listinfo/gllug" rel="noreferrer" target="_blank">https://mailman.lug.org.uk/mailman/listinfo/gllug</a><br>
</blockquote></div>