Henry V Child
b3a1718a62
All checks were successful
Generate and upload hugo website / generate_and_upload_site (push) Successful in 23s
83 lines
3.3 KiB
Markdown
83 lines
3.3 KiB
Markdown
---
|
|
date: 2025-04-13T00:00:00+00:00
|
|
draft: false
|
|
title: Testing IPv6 precedence
|
|
tags:
|
|
- 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!
|