160
Announcing .self: A New Top-Level Domain Designed to Support Self-Hosting (hccf.onmy.cloud)
submitted 4 months ago by to c/technology@lemmy.world
60 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 4 months ago (5 children)

How is IPv6 harder to understand? It's just IPv4 with all the uncommon stuff stripped out and put into optional headers (which IPv4 also has), and a much longer address now written in hex.

CGNAT is just a fancy term for NAT done by a carrier. They get a special private IP address range for doing so, but fundamentally it's still NAT.

Now IP multicast, THAT is complicated for humans to understand. Especially the whole subscriber logic.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 4 months ago (4 children)

    I'm taking this as a genuine question, so I'll answer for myself personally. My mental model of IPv4 is quite simple. A computer doesn't have an address unless you configure one for it, or a DHCP server gives it one. If you are on the same network and there's no firewall, knowing the ip address lets you reach the computer. The router has one public facing IP address that all your devices have to share, which is inconvenient.

    In ipv6, a computer has two automatic addresses from the MAC address, a link local and a real one, but they aren't interchangeable, and don't always work. Instead of DCHP, there is something else that prevents ip collisions somehow, but dhcp also still exists sometimes.

    In my limited experience, i can never count on reaching a device by its hostname, but if i know a local ipv4 address, that's enough, and they're easy to remember since only the last part really changes. With ipv6 the address is too long and incomprehensible to remember.

    I love that ipv6 works better for computers, that you don't have to worry about NAT traversal, but i don't think it is too hard to understand why humans find using it day to day more confusing if they're used to ipv4.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 4 months ago (3 children)

    link local

    IPv4 has this too. It's normally not routable so it's safe to ignore in both IPv4 and IPv6.

    Instead of DHCP...

    The following is a gross simplification, but works for understanding the most common cases:

    The original (heavy emphasis on this word) idea of IP is that addresses are unique for every interface. Additionally MAC addresses (48 bits) are also unique for every interface.

    In IPv4, you're trying to make interfaces that are unique in 48 bit IDs unique in 32 bit IDs. It doesn't take a pigeon to realize there will be collisions. Therefore you need a person to manually assign addresses. If you automate that person, that becomes DHCP.

    In IPv6, you're making a 48 bit unique ID unique in a 128 bit namespace. You literally don't need to do anything and you can still guarantee it's unique. That's how you automatically assign IPv6 addresses without DHCPv6.

    As for how MAC addresses are assigned uniquely, the first 24 bits are a vendor prefix. The vendors then ensure each device they produce is unique.

    With ipv6 the address is too long and incomprehensible to remember.

    The problem is that nobody should be memorizing arbitrary 128 bit numbers, or even 32 bit arbitrary numbers. Especially since the numbers don't even correspond to a machine, but instead an interface on the machine. Yes, 32 bit IPv4 addresses are easier to memorize, but you shouldn't be memorizing them in the first place. Services run off of names. If the names aren't working, fix the name service.

    Ideally NDN solves this problem completely. Every host/packet is identified by a name, not an address. If you need to fetch something, all you need to do is provide the name and somebody (doesn't have to be the original machine) will provide it to you.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 4 months ago* (last edited 4 months ago) (2 children)

    So a problem just came up today that encapsulates why IP addresses are still useful.

    I have a webservice at http://jeopardy.local:9981, but typing that into a web browser gives "Server Not Found".

    But if I type in http://<ipaddress>:9981 it works perfectly.

    It turns out that the problem is that flatpak Web browsers can't resolve mdns names.

    The world is full of stuff like this which unfortunately makes ip addresses the most reliable way to reach selfhosted services.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 4 months ago* (last edited 4 months ago) (1 child)

    The point I'm making is that IP addresses are useful/used because they are the canonical way of reaching a service. If you have a name (via DNS), it still needs to be translated into an address because routing depends on arbitrary numerical addresses.

    But they shouldn't be, and they don't have to be. They identify an interface, not the host. We have services on a single host running across multiple interfaces (multiple ports), or in some cases multiple services running on a single interface (k8s, cloudflare), or even sometimes multiple interfaces/servers masquerading as a single interface (DNS root servers).

    The correct way to handle this is to identify services by a name, which means routing itself should be handled via name, not IP addresses. This is one of the things Named Data Networks (NDN) tries to solve. In this scheme, everything has a name. Not a numeric address. Memorizing 10.0.0.1 becomes a lot less important when you can always reach your service at "foo/bar/service".

    Needless to say, this is currently not feasible because every single IP router in the world needs to be replaced with a NDN router, in which nobody would do. Vendors have already shown that when they can adapt new technologies or implement NAT, they will implement NAT.

    Edit NDN wikipedia article https://en.wikipedia.org/wiki/Named_data_networking

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •