Added PREF64 - #11
Conversation
DavidSchinazi
left a comment
DavidSchinazi
left a comment
There was a problem hiding this comment.
Thanks for writing this!
|
|
||
| Prefix: | ||
|
|
||
| : The highest 96 bits of the IPv6 prefix, encoded in network byte order. |
There was a problem hiding this comment.
| : The highest 96 bits of the IPv6 prefix, encoded in network byte order. | |
| : The highest 96 bits of the IPv6 prefix, encoded in network byte order. Note that | |
| this field is always 96 bits long, regardless of the value in the Prefix Length field | |
| preceding it. The unused low order bits at the end of this field MUST be set to zero. |
There was a problem hiding this comment.
I am not sure about MUST in "low order bits MUST be set to zero". RFC6052 specifically defines that lower bits are supposed to form suffix and SHOULD be set to zero. Is there another reference that mandates zero-filled suffix? If so, maybe we should make this field variable length and do not pass around meaningless zeros?
There was a problem hiding this comment.
Oh, you're right - I actually didn't know about the suffix:
There are no remaining bits, and thus no suffix, if the prefix is 96
bits long. In the other cases, the remaining bits of the address
constitute the suffix. These bits are reserved for future extensions
and SHOULD be set to zero. Address translators who receive IPv4-
embedded IPv6 addresses where these bits are not zero SHOULD ignore
the bits' value and proceed as if the bits' value were zero. (Future
extensions may specify a different behavior.)
So, in practice those bits are almost always zero, but we shouldn't mandate they be zero. Let's just pass them through like you have it, but maybe still add a note:
| : The highest 96 bits of the IPv6 prefix, encoded in network byte order. | |
| : The highest 96 bits of the IPv6 prefix, encoded in network byte order. Note that | |
| this field is always 96 bits long, regardless of the value in the Prefix Length field | |
| preceding it, see {{Section 2.2 of !RFC6052}} for details. |
There was a problem hiding this comment.
I've changed field name to "IPv6 Address Format" to reflect that it potentially includes both prefix and suffix and adjusted text accordingly. Please review.
There was a problem hiding this comment.
I find this text harder to reason about. I think the previous text was fine, and matched what 8781 had. If we're unsure let's just copy 8781 and have a reference to 6052 for details.
There was a problem hiding this comment.
Looks like this is the right balance. Please review once again.
|
|
||
| : The highest 96 bits of the IPv6 prefix, encoded in network byte order. | ||
|
|
||
| ## Handling |
There was a problem hiding this comment.
Can you add a sentence like "If an endpoint receives a capsule that does not meet one of the requirements above, or with a length that is not a multiple of 13 bytes, it MUST treat it as malformed. Note that an empty PREF64 capsule is valid; it indicates that no NAT64 prefixes are available on this network."
There was a problem hiding this comment.
Done. Please check
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
|
Thanks for the discussion! Feel free to merge and submit a draft revision |
|
Looks like I am not blessed with the rights to merge or publish releases. I can only "Comment" and "Close with comment" |
|
Oh. I tried to fix it but I don't have admin access, so I can't grant you those rights. Can you ping the chairs? |
2 participants
No description provided.