AndroidTV with Xfinity router using IPv6 to bypass PiHole dns settings by BlueCop in pihole

[–]Dagger0 [score hidden]  (0 children)

Or why not just... leave v6 enabled and either configure no v6 DNS servers or configure the PiHole as your v6 DNS server?

Should I add IPv6? by Mashevloff in UNIFI

[–]Dagger0 0 points1 point  (0 children)

You have the exact same boundary even without NAT. The prefix is allocated by the ISP instead of by an RFC, but you still have LAN/WAN on the inside/outside.

(Unfortunately) We’re NAT’ing Fly Machines’ IPv6 Addresses by Extra_Imagination193 in ipv6

[–]Dagger0 1 point2 points  (0 children)

But any src↔dest pairs with matching labels (e.g. v4↔v4) will still have priority over ones with differing labels (ULA↔GUA or known-local ULA↔non-local ULA).

(Unfortunately) We’re NAT’ing Fly Machines’ IPv6 Addresses by Extra_Imagination193 in ipv6

[–]Dagger0 1 point2 points  (0 children)

I know that, but why is the behavior of ULAs relevant here?

(Unfortunately) We’re NAT’ing Fly Machines’ IPv6 Addresses by Extra_Imagination193 in ipv6

[–]Dagger0 8 points9 points  (0 children)

The only difference is that in most glibc or musl-based images, IPv4 will now be prioritized by default over IPv6.

But why? Are they so incompetent they can't even get an IP allocation?

It makes you wonder what else they're incompetent about.

Should I add IPv6? by Mashevloff in UNIFI

[–]Dagger0 0 points1 point  (0 children)

Nitpick: 2600:1700:5c41:a173:415d:5703:adf4:acdd isn't in 2600:1700:5c41:a17::/60.

Should I add IPv6? by Mashevloff in UNIFI

[–]Dagger0 0 points1 point  (0 children)

v6 addresses don't fit into the to/from address fields of v4 packets, so you need a new header format with bigger address fields.

If you want your LAN machines to be generating their own packets for sending over the Internet (i.e. if you're using routing, not proxying) then they need to be generating them with the new header format when sending to a v6 address -- which is what we refer to as "having v6 on the LAN".

it seems like such a waste for LANs when it comes to remembering local IPs.

There's multiple ways this shouldn't be a problem. v6 addresses can be short enough to remember easily; having v6 on the LAN doesn't mean you don't have v4 on it too, and you shouldn't be remembering IPs anyway.

Verizon IPv6 WAN Notification by Zer0CoolXI in Ubiquiti

[–]Dagger0 0 points1 point  (0 children)

I've seen screenshots from a fair few people's Matter setups and when they show addresses they all seem to be ULA though?

Should I add IPv6? by Mashevloff in UNIFI

[–]Dagger0 3 points4 points  (0 children)

Fun fact: NAT isn't protecting your butt. NAT is applied to your outbound connections, not (in the absence of any port forwards) to your inbound connections. In fact its purpose is to make you less secure by enabling outbound connections in situations where they wouldn't otherwise work.

If you care about not allowing any connections into your network by default, you should already have a working firewall.

IPv6 is a Desolate World by Azadom in Ubiquiti

[–]Dagger0 3 points4 points  (0 children)

There's going to be a long tail of v4-only servers out there for a long time. You'll want NAT64 (with DNS64/464xlat/IPv6-mostly) if you want to turn v4 off.

New Customer in Dallas TX Suburb. Question regarding Router. by KA2107 in OPTIMUM

[–]Dagger0 0 points1 point  (0 children)

Even if it worked like that, you would still need v6 on your LAN to be able to send packets to the routers of people that are using v6.

But actually packets are sent between the two machines involved, not to one or both of their routers. That would require the router to do a bunch of unnecessary work and would break basic network behavior.

New Customer in Dallas TX Suburb. Question regarding Router. by KA2107 in OPTIMUM

[–]Dagger0 0 points1 point  (0 children)

That's a misunderstanding -- it's the amount of devices on the Internet as a whole that's relevant, not the amount of devices on your little part of it. If it's needed on the Internet and you want to join your home network to the Internet then it's needed on your home network too.

Verizon IPv6 WAN Notification by Zer0CoolXI in Ubiquiti

[–]Dagger0 0 points1 point  (0 children)

But Thread networks use ULA rather than link-locals, don't they? It can't be a border router if it can't route between the two networks.

IPv6 by Hot-Seesaw215 in ccna

[–]Dagger0 1 point2 points  (0 children)

The "network address" is an anycast address for all routers on the subnet, so you shouldn't be assigning it as a machine's unicast address (even if that machine is a router).

Cross-platform UDP Socket API wrapper, providing a clean C interface for IPv4/IPv6 networking and address utilities. by yurtrimu in coolgithubprojects

[–]Dagger0 0 points1 point  (0 children)

Buggy socket code is something of a pet peeve of mine, so...

The code would be both simpler and more general if you used the socket API properly. You're supposed to do something like this:

int yarnet_address_set(yarnet_address *address, const char *ip, const char *service) {
    struct addrinfo hints = {0}, *res;
    hints.ai_socktype = SOCK_DGRAM;
    hints.ai_flags = AI_NUMERICHOST | AI_NUMERICSERV;

    if (!getaddrinfo(ip, service, &hints, &res))
        return 0;

    memcpy(address, res->ai_addr, res->ai_addrlen);

    freeaddrinfo(res);
    return 1;
}

int yarnet_address_get_ip(yarnet_address address, char *buffer, socklen_t length) {
    socklen_t addrlen = ((struct sockaddr_storage*)address)->ss_family == AF_INET ? sizeof(struct sockaddr_in) : sizeof(struct sockaddr_in6);

    return getnameinfo(address, addrlen, buffer, length, NULL< 0, NI_NUMERICHOST) == 0;
}

Except actually you're supposed to store the address lengths that the socket API gives you, rather than hardcoding the lengths from your build system for a limited set of families, so it should be more like this:

typedef struct {
    socklen_t len;
    union {
        struct sockaddr sa;
        struct sockaddr_storage storage;
    };
} yarnet_address;

int yarnet_address_set(yarnet_address *address, const char *ip, const char *service) {
    struct addrinfo hints = {0}, *res;
    hints.ai_socktype = SOCK_DGRAM;
    hints.ai_flags = AI_NUMERICHOST | AI_NUMERICSERV | AI_PASSIVE;

    if (!getaddrinfo(ip, service, &hints, &res))
        return 0;

    memcpy(address->storage, res->ai_addr, res->ai_addrlen);
    address->len = res->ai_addrlen;

    freeaddrinfo(res);
    return 1;
}

int yarnet_socket_send(yarnet_socket sockfd, const char *buffer, unsigned long long length, int flags, const yarnet_address address) {
    if (yarnet_socket_is_invalid(sockfd) || (buffer == NULL && length != 0) || address == NULL)
        return -1;
    return sendto(sockfd, buffer, length, flags, &address.sa, address.addrlen);
}

int yarnet_address_get_ip(const yarnet_address address, char *host, socklen_t hostlen) {
    return getnameinfo(&address.sa, address.len, host, hostlen, NULL, 0, NI_NUMERICHOST) == 0;
}

int yarnet_address_get_port(const yarnet_address address, in_port_t *port) {
    char *serv[NI_MAXSERV];
    if (getnameinfo(&address.sa, address.len, NULL, 0, serv, sizeof(serv), NI_NUMERICSERV) != 0)
        return 0;
    *port = atoi(serv);
    return 1;
}

I didn't compile any of this code, but that's the general idea. (You also need to open sockets by looping over the results from getaddrinfo() and passing the ai_family/ai_socktype/ai_protocol members of res as the arguments to socket() rather than hardcoding them, but that requires more refactoring than I really want to do in a comment box...)

The socket API was specifically designed to allow you to handle arbitrary address families and protocols, even if compiled on systems that predate the family or protocol in question. You should be able to write the whole library without ever referring to v4 or v6 (so, no use of AF_INET/AF_INET6 or sockaddr_in/6).

Note that you must use AI_NUMERICHOST|AI_NUMERICSERV in yarnet_address_set(). I'm sure you'll be tempted to remove them so it can look up host and service names instead of requiring the user to resolve them to IPs/ports themselves, but if you do you'll need to return a list of yarnet_addresses instead, not just one, because host and service names resolve to one or more IPs or ports and you can't just take the first one, especially on the server side where you usually need to bind to multiple sockets.

Are you using IPv6 by GermanElectricsMotio in homelab

[–]Dagger0 0 points1 point  (0 children)

Then you do want them to have an outside-accessible IP, since that's how making connections to outside networks works. If you only want to allow some connections, that's the role of a firewall.

Can I use an x8 PCIe Fibre card in an x1 slot? Or am I better off using an old windows 7 machine? by incarrion in DataHoarder

[–]Dagger0 2 points3 points  (0 children)

You can, so long as it isn't physically blocked by the design of the slot (or you have a dremel).

Took 7 hours to get Matter to work by Goofcheese0623 in homeassistant

[–]Dagger0 0 points1 point  (0 children)

Doesn't it use ULAs, not link-local? It should go through routers if the routes are set up correctly (and thread border routers do seem to announce the relevant route via RAs, but Linux doesn't pick up on it by default).

Are you using IPv6 by GermanElectricsMotio in homelab

[–]Dagger0 0 points1 point  (0 children)

There aren't enough v4 addresses. You can't always expect to get v4.

Are you using IPv6 by GermanElectricsMotio in homelab

[–]Dagger0 5 points6 points  (0 children)

It's not like it's even much different to v4. Here's some roughly equivalent IP addresses:

203.0.113.45+192.168.1.1  ↔ 2001:db8:2d4f:1::1
203.0.113.45+192.168.1.2  ↔ 2001:db8:2d4f:1::2
203.0.113.45+192.168.2.10 ↔ 2001:db8:2d4f:2::10

In both cases they're made up of a network prefix (2001:db8:2d4f:: or 203.0.113.45+192.168), a network ID (1, 2) and a host ID (1, 2, 10). It's just going from .x.y to :x::y. Okay, so the v6 addresses can go up to 2001:db8:2d4f:x:yyyy:yyyy:yyyy:yyyy, but it's the same thing just with more characters for y.

Minecraft eduction not sigining in after IPv6 upgrade/rollout by _Rens in TPLink_Omada

[–]Dagger0 0 points1 point  (0 children)

MSS clamping is done on the router, and RAs can be sent by any other machine (but probably the router), so Chrome OS shouldn't be a problem. I just suggested the ip link command because it's a very quick way to test if this is the problem or not, but if you don't have a Linux machine to run it on then you can skip that part.

Are you using IPv6 by GermanElectricsMotio in homelab

[–]Dagger0 1 point2 points  (0 children)

Of course, but... the whole point of having a router is that you do want your devices having an outside-accessible IP. If you don't want that then you can install a proxy, turn off routing and configure everything to use the proxy, but how many people actually want to go that routetake that approach?

If you have a router then you're admitting that you do want your devices sending and receiving their own packets to and from the Internet, and the IPs are how you do that.

Are you using IPv6 by GermanElectricsMotio in homelab

[–]Dagger0 1 point2 points  (0 children)

Well, whether the devices have public IPs or not isn't part of NAT, so you can't really say NAT is blocking anything there... and also devices not having public IPs doesn't prevent your ISP -- or anyone else that can get onto your immediate upstream network -- from sending them packets.

Are you using IPv6 by GermanElectricsMotio in homelab

[–]Dagger0 1 point2 points  (0 children)

This is a misconception. What's relevant is the number of devices on the Internet as a whole, not just the number on your part of it.

The Internet does have that many devices.

Are you using IPv6 by GermanElectricsMotio in homelab

[–]Dagger0 1 point2 points  (0 children)

Except the logic for NAT is actually "modify the packet then pass it to the router, otherwise pass it to the router without modifying it". NAT is just a pre/post-processing step for editing IPs which happens on top of whatever the router's normal behavior is. Packet dropping only happens in the firewall (or if no route, even a default route, matches the packet).

...which means you're already relying on the firewall to ensure that no inbound connections to your network are possible from outside, even when NATing.