Album on lemmy.ca, beehaw.org, shit.itjust.works & lemmy.world

  • 0 Posts
  • 19 Comments
Joined 1 year ago
cake
Cake day: June 7th, 2023

help-circle









  • Your prefix can change yes but the recommendation is that it shouldn’t in practice. You’ll find ISPs doing it right will extend your PD lease infinitely unless you release it for a long enough period of time. Similar to ipv4.

    The privacy is similar to ipv4 also. All your traffic on ipv4 looks like it’s coming from your WAN IP… Your PD is in this sense equivalent (though not literally equivalent for all the pedants reading) to your WAN IP.


  • Album@lemmy.catoSelfhosted@lemmy.worldA Short IPv6 Guide for Home IPv4 Admins
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    1
    ·
    5 months ago

    It’s honestly super simple to set up. Outside of your ISP config it’s almost all autoconfig. 100% of the complication (at least for me) comes from knowing ipv4 first for 20 years and then trying to incorrectly map those concepts to V6.

    As soon as I “let go” it was fine.

    There’s not a huge net benefit you’re right. I mostly wanted to learn and I hope to be at the front edge of disabling ipv4 in the near distant future.



  • Ipv6 requires fundamental rethinking about how addressing is done. If you’re trying to apply v4 concepts to V6 you likely end up running into something they intentionally designed out.

    A unique local address is an address space where you could do that. It’s the equivalent to RFC1918 eg. 172/192/10. So you could statically assign fd0::x, and that is expected, but not required generally.

    I wouldn’t give each device a static unique global address unless they need to be accessed via wan without domain consistently. You lose device privacy really quickly that way because every device gets a unique globally routable address. It’s fine for internet facing services but most Linux, Windows, and mobile implementations are using ipv6 privacy extensions by default to ensure you get a random GUA every day.

    My network is dual stack and I connect mostly over ipv6 to all my internal clients using internal DNS. If my internal DNS is ever down I can fall back to ipv4 or it’s basically the one box on my network with an easy to remember ULA.






  • I take “federated email” to refer to a juxtaposition with normal email implementation which harkens back to how it was in the 90s or early 00s where you didn’t need to be registered on many SMTP servers in order to use it and it’s stripped of server-side validation. There’s some discussion on this topic in the fediverse.

    You’re right that the default current implementation is already federated.


  • Your own email server requires near 100% uptime or you risk not receiving critical emails. If a remote email server is trying to contact your email server and it can’t it’s only going to retry a few times and then give up. Hosting this yourself sounds great until you realize high uptime is not cheap and requires constant attention.

    Setting it up securely can be difficult depending on your understanding of server infrastructure as well as protocols like DNS. You need to set up SPF, DKIM, DMARC, etc in order to prevent someone from faking an email from your server.

    Of course, federated email does not use SPF/DKIM/DMARC because the whole point is that someone from another server could use your server to send an email (hence the federation). Open email servers were common 20 years ago but very rare today. That makes setup easier, but the main caveat is that most known non-federated email servers will reject email from servers that don’t have SPF/DKIM/DMARC because they generally end up being havens for bots and spam since there is no verification or authenticity of the sender.

    As someone who self hosts a lot of things, I would never self host my email. If i did I would be paying for two boxes in different parts of the world on different ISPs to provide that uptime. I would definitely set it up securely and not as a federated server otherwise it would be practically unusable for day to day emails.