Re: [MBONED] draft-ietf-mboned-64-multicast-address-format-03.txt

[Tim Chown <[e-mail]>]

On 15 Aug 2012, at 02:43, Stig Venaas <[e-mail]> wrote:

> On 14.08.2012 14:43, Lee, Yiu wrote:
>> Hi Stig,
>> 
>> Since we want T=1, this will not meet the "well-known" requirement defined
>> in RFC4291. If we don't want to define a flag, what is the proper way to
>> describe ffxx:8000::/20 and ffxx:0:8000::/96?
> 
> You could list them for all values of xx perhaps. I would maybe use
> "x" and "y" and then discuss the allowed values.
> 
> There are scope relative allocations today, the main thing is that we
> don't want to require the flags to be "0". Or maybe we want to require
> the T-bit to be set. As I wrote earlier, I would think of these
> addresses as transient, and T=1 is required for Embedded-RP etc.
> 
> The issue though is that if T=1, then it is not really an IANA
> allocation as I see it, because IANA allocations have T=0. But if there
> is IETF consensus, then one can still reserve these prefixes.

I agree with Stig; there are multiple prefixes being reserved here.

The text is effectively updating both RFC3306 and RFC3956 since the above prefix is setting a bit in the reserved bit range of both those specifications.  RFC3306 also says all those reserved bits (17-24) must be zero, while RFC3956 doesn't explicitly say that for bits 17-20 (it probably should, if you're now using one of those bits).

Both RFCs say that if R or P flags are set, then T must be set too, so I'm not sure you have freedom to say "if T=1" if you want to support those two methods. 

Finally, it may make more sense to use ffxx:1000::/20 for ASM, and thus only use the rightmost bit of the four reserved bits (for RFC3956 at least)?

Tim