snabelen.no er en av mange uavhengige Mastodon-servere du kan bruke for å delta i det desentraliserte sosiale nettet.
Ein norsk heimstad for den desentraliserte mikroblogge-plattformen.

Administrert av:

Serverstatistikk:

371
aktive brukere

#ipv6

45 innlegg39 deltakere5 innlegg i dag

This may sound like a dumb question, but with IPv6 am I supposed to ... learn the addresses like I have for IPv4?

With IPv4 I feel as if I have had a reasonable chance of learning some of the important blocks, but with IPv6... I genuinely hesitate to "adopt" because I fear having to learn the new addressing scheme.

If not, how should I ... "think" about IPv6 coming from the perspective of actually knowing IPv4-addresses?

IPv6 question:

There's a /64 subnet (using ULAs, so addresses are stable). All hosts on the subnet have static addresses, there is no SLAAC or DHCPv6. Those hosts have their addresses configured with /64 masks so they are able to communicate with each other directly.

There's also a router attached to that subnet, which provides access to other networks. That router emits RAs as a good IPv6 router should 🙂

The question is: is there any value to including this ULA prefix in the RAs themselves? Since the "M", "O", and "Autonomous" bits will all be 'false', how would the hosts benefit from the prefix being included in the RAs?

(This subnet is already alive and traffic is flowing as planned, so this question is mostly about "have I missed something", not "how do I make this work")

We are hiring for both a Director of Product Management and a Senior Product Architect for Cloud Networking (eg, within #Linode / #akamai_technologies Cloud). The former is a remote US position while the latter is a remote Czechia/Poland position.

Come help specify and design a modern cloud networking platform (eg, utilizing IPv6-centric design patterns, while also meeting legacy IPv4 needs).

jobs.akamai.com/en/sites/CX_1/

jobs.akamai.com/en/sites/CX_1/

I love working at Akamai which is why I've been at the company for 26 years now. We have lots of great employees, a global culture that values diversity and inclusivity, and no shortage of fun problems to solve.

Akamai Career SiteSenior Product Architect (Cloud Networking) - RemoteAs a Senior Product Architect you will drive innovative solutions for our rapidly growing Cloud networking products. You will help shape the next generation of our Cloud networking products and platforms. This includes Virtual Private Cloud (VPC), Cloud Firewall, TCP/UDP Cloud Load Balancer, Direct Connect.
I have a strange issue when enabling dhcp option 108 / nat64 / etc on my #ipv6-mostly home network. I don't quite know what to make of it.

I use the apalrd fork of tayga to do NAT64. This is working great. Of note: my nat64 translator is using the well known prefix and is configured to allow access to my internal rfc1918 network. I'm using kea-3.0 for dhcp option 108 support. As a result, no ipv4 addresses are assigned to apple/android devices and they activate their clat to use with my nat64 translator. dns64 is available as well for my #FreeBSD jails etc (which also have no ipv4 but may need to reach github etc). This is all working fine.

EXCEPT.. I have a couple of tp-link tapo C125 cameras in homekit-secure-video mode. Mostly for pet doors etc. They don't seem to like to work in ipv6-only mode even though they did acquire an ipv6 address. These are working fine with apple home and do the motion detection / record video / etc thing. I can browse the recorded video just fine. So far so good..

However, if I try to check *live video* (vs icloud recorded), then the apple gear seems to try to talk to it via ipv4 directly - without having an ipv4 address on that vlan. When looking at a phone that is involved, I see the local clat (on 192.0.0.2) and all the ipv6 addresses. And yet, it seems to be sending direct 192.0.0.2 -> 10.0.0.41 (the camera) packets on the network. Which of course, replies and the replies go to the freebsd router which drops them because they're garbage.

Thoughts:

* I know I'm not supposed to allow a nat64 on the private well-known prefix to reach back into rfc1918 space. That's fine for carrier stuff really dumb for a home network.

* Everything in the apple universe seems perfectly happy with this arrangement and uses clat/nat64 just fine.. EXCEPT live video on those couple of cameras. Is this just apple being weird?

* Kea is giving a dhcp4 reply of: "dns: 10.0.0.1, subnet mask: 255.255.255.0, option 108: 1800 seconds.". This is a bit strange. It's not assigning a pool address, nor a fixed reservation.. so why the subnet mask?

* I am wondering if perhaps the apple stuff has some workaround kludges for the nat64 spec's handing of well-known-prefix vs rfc1918 space? Maybe it is doing something like sniffing mdns or dhcp replies for other devices and using that to infer what the local network is?

* Older versions of Kea don't do dhcp option 108 properly - they tell the client to "turn off the ipv4 stack but also use this ipv4 address". Maybe apple inadvertently rely on this kind of quirk? I'm wondering if homekit secure video might have used the ipv4 address that older kea would have assigned anyway. I'll check that out in a while.

Does anyone recognize this? I'm going to tinker with the stuff I mentioned above. I figure its a long shot but maybe somebody might have an "AHA! that's easy, just do X, Y and Z!"

From ip6addrctl(6):

"The precedence and label arguments are decimal numbers, which specify the precedence and label values for the entry, respectively."

Gee, thanks. That is super helpful. /s The entire man page is about this useful, you have to go digging into RFC 6724 to get anything useful out of this command. You couldn't just specify that higher preference is preferred in the man page? There is literally nothing about the selection process in the man page.

If you happen to be on a system with IPv6-only connectivity and you have to use a #Java software, you may want to add -Djava.net.preferIPv6Addresses=true as param to force Java to use #IPv6. Java still uses #IPv4 as default which will not work on IPv6-only systems.

On the positive side, I discovered today that #ionos finally allows vserver customers (compared to their cloud computing offering) to set reverse DNS records on #IPv6 addresses. This finally allows me to send email via IPv6 over them (besides the similarly configured netcup instance I additionally have and which provides this functionality since years).

Cool set of tools linked to today in a presentation in the #IETF #HAPPYWG session:

happy-eyeballs.net/

It allows you to characterize the Happy Eyeballs behavior of a client, such as to see how much of a delay in DNS resolution or TCP connection response triggers a failback from IPv6 to IPv4.

See more details in Dave Plonka's talk:

datatracker.ietf.org/meeting/1

www.happy-eyeballs.netHappy Eyeballs Webtester

What I want from #Mozilla: Overhaul their infrastructure so I can reach all[1] of their resources via #IPv6

What we get from Mozilla: AI 😔

[1] It only took them 7 years to get addons.mozilla.org working: bugzilla.mozilla.org/show_bug. . firefox.com now answers on IPv6 but links to download.mozilla.org which does not. Their infra is such a hodge-podge.

bugzilla.mozilla.org1354049 - AMO does not support IPv6 anymore, only IPv4RESOLVED (wezhou) in Cloud Services - Operations: AMO. Last updated 2024-11-02.