henryv/www.henryvchild.eu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

New post: Testing IPv6 precedence
All checks were successful
Generate and upload hugo website / generate_and_upload_site (push) Successful in 23s
Details

Browse Source
This commit is contained in:
Henry V Child 2025-04-13 11:59:26 +02:00
parent a2a6464716
commit 1f64c6d716
1 changed files with 83 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
content/posts/2025/Testing IPv6 precedence/index.md Normal file
View File

@ -0,0 +1,83 @@
---
date: 2025-04-13T00:00:00+00:00
draft: false
title: Testing IPv6 precedence
tags:
- Post
- IPv6
- Networking
---
## The Theory
Many sources on the internet claim that IPv6 unique local addresses (ULAs) are broken in dual stack environments, that is environments that have both IPv4 and IPv6 deployed. Sources usually point to RFC 6724 to prove that ULA's don't work.
The RFC 6724 precedence table:
| Prefix | Precedence | Label |
| ------------- | ---------- | ----- |
| ::1/128 | 50 | 0 |
| ::/0 | 40 | 1 |
| ::ffff:0:0/96 | 35 | 4 |
| 2002::/16 | 30 | 2 |
| 2001::/32 | 5 | 5 |
| fc00::/7 | 3 | 13 |
| ::/96 | 1 | 3 |
| fec0::/10 | 1 | 11 |
| 3ffe::/16 | 1 | 12 |
So, according to this table an IPv4 address (represented by ::ffff:0:0/96 ) should be preferred over ULAs (represented by the prefix fc00::/7 ). This would then make IPv6 ULAs
## The Test
I tested this on my own home network. The remote host is a Debain container running on Proxmox. And the client is Arch Linux running on a laptop.
```
[henryv@HenryV-T480 ~]$ nslookup ula-test.henv.eu
Server: 10.221.183.1
Address: 10.221.183.1#53
Name: ula-test.henv.eu
Address: 10.155.69.113
Name: ula-test.henv.eu
Address: fd7a:18a6:838d:1:be24:11ff:fecb:60
```
An Pv6 ULA and an IPv4 address have been configured on the remote host. And as can be seen both addresses have been added to the networks DNS server. Now a ping is executed on the client to see what address is used.
```
[henryv@HenryV-T480 ~]$ ping -c 4 ula-test.henv.eu
PING ula-test.henv.eu (fd7a:18a6:838d:1:be24:11ff:fecb:60) 56 data bytes
64 bytes from ula-test.henv.eu (fd7a:18a6:838d:1:be24:11ff:fecb:60): icmp_seq=1 ttl=63 time=0.808 ms
64 bytes from ula-test.henv.eu (fd7a:18a6:838d:1:be24:11ff:fecb:60): icmp_seq=2 ttl=63 time=1.20 ms
64 bytes from ula-test.henv.eu (fd7a:18a6:838d:1:be24:11ff:fecb:60): icmp_seq=3 ttl=63 time=1.24 ms
64 bytes from ula-test.henv.eu (fd7a:18a6:838d:1:be24:11ff:fecb:60): icmp_seq=4 ttl=63 time=0.835 ms
--- ula-test.henv.eu ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.808/1.018/1.235/0.197 ms
```
This is not the expected result! the ULA address was chosen over the IPv4 address.
To check if the IPv4 address is in fact functioning ping was forced to use IPv4.
```
[henryv@HenryV-T480 ~]$ ping -4 -c 4 ula-test.henv.eu
PING ula-test.henv.eu (10.155.69.113) 56(84) bytes of data.
64 bytes from ula-test.henv.eu (10.155.69.113): icmp_seq=1 ttl=63 time=0.577 ms
64 bytes from ula-test.henv.eu (10.155.69.113): icmp_seq=2 ttl=63 time=0.871 ms
64 bytes from ula-test.henv.eu (10.155.69.113): icmp_seq=3 ttl=63 time=0.994 ms
64 bytes from ula-test.henv.eu (10.155.69.113): icmp_seq=4 ttl=63 time=1.11 ms
--- ula-test.henv.eu ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.577/0.888/1.110/0.198 ms
```
And it indeed works.
## The Result
I'm not sure what kind of optimisation is going on under the hood to produce this behaviour. I have not changed `/etc/gai.conf` so the precedence table should be using it's default values as per RFC 6724.
This is However the behaviour I wanted on my network so I will setup ULA without fear on my network!