[GLLUG] Direct Fibre To The House

[John Hearns]

I have Hyperoptic. They are superb.
They originally only worked with apartment blocks - I believe this is no
longer so.
In our block they have a rack high up on a wall downstairs and every
apartment has a CAT5 line run up to it.
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.

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.





On Mon, 29 Aug 2022 at 21:24, Andy Smith via GLLUG <gllug at mailman.lug.org.uk>
wrote:

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