NAT64/Teredo Embedding Strategies + Public/Private Blocks#105
Open
zanbaldwin wants to merge 6 commits into
Open
NAT64/Teredo Embedding Strategies + Public/Private Blocks#105zanbaldwin wants to merge 6 commits into
zanbaldwin wants to merge 6 commits into
Conversation
Add embedding strategy for NAT64 "Well-Known Prefix" `64:ff9b::/96` defined by RFC 6052 § 2.1 (with test coverage and data providers). Include docblocks for the other strategies that explain their defining RFC.
Add composite embedding that delegates checks/extraction to multiple underlying strategies (always uses first-defined strategy for packing). Named constructor `all()` covers all unambiguous, non-deprecated embedding, with Mapped as the canonical packer. Includes test coverage and data provider.
isUnicastGlobal() only inspected 16-byte IPv6 form, meaning a non-global IPv4-embedded address (loopback, private, etc) was reported as global. Error also cascaded down to isPublicUse(). Bug could potentially allow a non-global address to slip past an SSRF/ACL guard/deny-list. Embedded addresses are now canonicalised before classifying. Note: IPv6 now checks ALL valid IPv4-embeddings (previously only Multi checked, and only checked its singularly-assigned embedding).
Add extraction-only embedding strategy for the Teredo tunnelling prefix `2001::/32` defined by RFC 4380 § 4 (with test coverage and data providers).
The IANA special-purpose registry lists the NAT64 local-use block `64:ff9b:1::/48` (defined by RFC 8215; different to the NAT64 well-known prefix) as not globally reachable, but `isUnicastGlobal()` and `isPublicUse()` report addresses within it as global. Fix: explicitly exlcude them. Operator-defined, cannot be decoded by an embedding strategy, must be excluded as a whole instead of being canonicalised.
Roman3349
reviewed
Jun 4, 2026
| * Globally reachable, but not reserved by protocol. RFC 6052 § 3.1 states that | ||
| * non-global IPv4 addresses must NOT be embedded as NAT64. | ||
| */ | ||
| class Nat64 implements EmbeddingStrategyInterface |
There was a problem hiding this comment.
Since NAT64 supports prefixes other than 64:ff9b::/96, would it be possible to add the option to specify a different checksum-neutral prefix for NAT64?
Member
Author
There was a problem hiding this comment.
I have been reading RFC specifications for nearly 2 days, so my brain needs a rest right now, but I have seen this and I will reply some time in the next couple of days 👍
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.