Chris Haynes wrote:
Just two little questions for whoever is working on the detailed mask proposals
(I lose track).
For the record, I will be working on and maintaining the mask proposal.
Did I miss the post where it was explained how 16-octet IPv6 address masks are
to be encoded and distinguished from IPv4 masks?
IPv6 masking was not explained in detail, but I gave the following
reference:
For IPv6, RFC3513 speficies how the net-blocks should be specified:
"The text representation of IPv6 address prefixes is similar to the
way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An
IPv6 address prefix is represented by the notation:
ipv6-address/prefix-length
where
ipv6-address is an IPv6 address in any of the notations listed
in section 2.2.
prefix-length is a decimal value specifying how many of the
leftmost contiguous bits of the address comprise
the prefix."
I would suggest that since the IPv6 Addressing RFC specifies a good way
to compress long strings of zeros in CIDR notation, that it is good
enough. IPv4 did not specify such a method when it was invented (that I
know of), but the current CIDR notation is rooted in common practice.
The following section details CIDR prefix notation:
http://rfc.net/rfc3513.html#s2.3
And is it defined what happens if the receiver has an IPv6 address to test, and
a mask is expressed only in IPv4, and vice versa?
Thank you for pointing this out. I think the only reasonable thing to
do, is if there are IPv4 masks but no IPv6 mask, it means that the
extension records do not contain any IPv6 addresses. Likewise, if there
are IPv6 masks but no IPv4 masks, it means that no IPv4 addresses follow.
If there are no masks of any kind, then there is no information about
what follows, and the redirects should be followed.
But if a m= modifier is present, it will be guaranteed to be complete.
Of course, if the record is so complicated and fragmented that the mask
doesn't fit, then no mask at all will be provided.
This above case may happen if the compiler's output ends up looking like
a string of mechanisms that cannot be compiled because they contain {i}
or {l} macros, or PTR or exists, and the remaining space at the end of
the record is not enough to squeeze in a _complete mask_
If you have suggestions on how the masks can be made better (shorter,
more efficient) or if you know of other corner cases that have not been
mentioned, I would appreciate if you'd pointing them out.
Regards,
Radu.