From 05728771caa3b58d1ab73ef91c5c09facb05544e Mon Sep 17 00:00:00 2001 From: Tore Anderson Date: Sun, 2 Feb 2025 09:33:38 +0100 Subject: [PATCH] Update doc regarding limitations on non-SLAAC nets The LIMITATIONS part of the documentation wasn't updated to take into account the changes in 81f2c61, fix that. Closes #24. --- README.pod | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/README.pod b/README.pod index 7af905f..bea8410 100644 --- a/README.pod +++ b/README.pod @@ -382,13 +382,23 @@ unset or 0, there is no default. =head1 LIMITATIONS -B will not be able to acquire an IPv6 address for the CLAT if SLAAC -isn't used. I suggests DHCPv6 IA_PD should be attempted in this -case, but this isn't currently implemented. +If no IPv6 addresses on the PLAT-facing device are EUI-64-derived (e.g., when +using SLAAC with I or I privacy addressing or static +addresses), B will generate and use an CLAT IPv6 address using a random +Interface ID from the same subnet prefix (if it is /120 or shorter). +I suggests DHCPv6 IA_PD should be attempted in this case instead, but +this isn't currently implemented. B will not attempt to perform Duplicate Address Detection for the IPv6 address it generates. This is a violation of I. +There is no guarantee that the generated CLAT IPv6 address is in fact usable, +as the network might block its use. + +If the upstream network is using DHCPv6, B will not be able to generate +a CLAT IPv6 address at all, due to the fact that DHCPv6-assigned addresses do +not carry a prefix length. + B will not attempt to perform a connectivity check to a discovered PLAT prefix before setting up the CLAT, as I suggest it should.