The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as RFC1918 #33
Conversation
| Note that some IPv4 prefixes are scoped to a given host or network, such as | ||
| 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, and 255.255.255.255/32, and | ||
| therefore do not require NAT64 address synthesis. | ||
| Additionally, the Well-Known Prefix {{!RFC6052}} MUST NOT be used to represent | ||
| non-global IPv4 addresses, such as those defined in {{!RFC1918}}. |
There was a problem hiding this comment.
I also think this whole paragraph should be at the end of the section for readability.
Be right before
Hostnames with Broken AAAA Records {#broken}
There was a problem hiding this comment.
If rfc6052 already says this, why is it relevant for HEv3?
There was a problem hiding this comment.
I think it makes sense to point out the NAT requirement to tell the clients to not bother. I'd phrase it something like this:
Similarly, there are additional restrictions on the use of the well-known NAT64 prefix (see Section 3.1 of RFC 6052) so clients can skip NAT64 address synthesis in such cases that will be rejected by the NAT64 translator.
There was a problem hiding this comment.
Great. Thank you. That text is better as we are talking of client implementation.
If moving the text down also seems reasonable please merge ;)
momoka0122y
changed the title
| @@ -480,6 +476,11 @@ queries; connection attempts follow the algorithm described above | |||
| Such translation also applies to any IPv4 address hints received | |||
| in SVCB RRs. | |||
|
|
|||
| Note that some IPv4 prefixes are scoped to a given host or network, such as | |||
There was a problem hiding this comment.
Not sure I fully understand the motivation for moving this down, but we can rearrange later editorially.
| Note that some IPv4 prefixes are scoped to a given host or network, such as | ||
| 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, and 255.255.255.255/32, and | ||
| therefore do not require NAT64 address synthesis. | ||
| Similarly, there are additional restrictions on the use of the well-known NAT64 prefix (see Section 3.1 of {{!RFC6052}}) so clients can skip NAT64 address synthesis in such cases that will be rejected by the NAT64 translator. |
There was a problem hiding this comment.
Style nit: This probably needs to wrap with the rest of the document (this is superseded by the suggested comment, though, so no worries).
| Note that some IPv4 prefixes are scoped to a given host or network, such as | ||
| 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, and 255.255.255.255/32, and | ||
| therefore do not require NAT64 address synthesis. | ||
| Similarly, there are additional restrictions on the use of the well-known NAT64 prefix (see Section 3.1 of {{!RFC6052}}) so clients can skip NAT64 address synthesis in such cases that will be rejected by the NAT64 translator. |
There was a problem hiding this comment.
I know this wording came from a previous comment, but perhaps something that would convey just the necessary bits would be something like:
| Note that some IPv4 prefixes are scoped to a given host or network, such as | |
| 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, and 255.255.255.255/32, and | |
| therefore do not require NAT64 address synthesis. | |
| Similarly, there are additional restrictions on the use of the well-known NAT64 prefix (see Section 3.1 of {{!RFC6052}}) so clients can skip NAT64 address synthesis in such cases that will be rejected by the NAT64 translator. | |
| Note that some IPv4 prefixes are scoped to a given host or network, such as | |
| 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, and 255.255.255.255/32, and there are | |
| additional restrictions on the use of the well-known NAT64 prefix (see | |
| {{Section 3.1 of !RFC6052}}), therefore NAT64 address synthesis might not be required. |
closes #32