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

[Behcet Sarikaya <[e-mail]>]

On Fri, Aug 17, 2012 at 1:06 PM, Stig Venaas <[e-mail]> wrote:
> Hi Tim
>
>
> On 8/16/2012 4:12 PM, Tim Chown wrote:
>>
>> 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).
>
>
> You're right about 3306. I wonder now if instead of practically
> reserving a specific value for the entire nibble of remaining
> reserved bits in 3306, it would be better to reserve just one of
> the bits. I don't think it updates 3956, because it doesn't talk
> about those bits at all, AFAICT.
>
>
>> 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.
>
>
> Yes, that's why I've been saying that we can't just get an IANA
> allocation. We need T=1 for this to work, and IANA is allocating
> ASM with T=0.
>
>
>> 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)?
>
>
> Yes, but it would mean that if in the future one wants to use a
> new reserved bit for another purpose, then it won't work for
> this purpose. I like the idea of using a single bit actually.
>
> So here is an alternative proposal. Do you think it's better?
>
> 1. Update 3306 and give a new meaning to one of the remaining
>    reserved bits.
>
> 2. Get a /96 for ASM from IANA (which would have T=0).
>
> The first would allow for 3306 and 3956 addressing, which I
> think is useful.
>
> The second would allow for uses where people don't care for
> that other type of addressing, and may also be useful if you
> want to use more or less fixed addresses, that does not use
> any particular unicast address.
>
> The alternative of just getting a /96 for ASM from IANA is
> in draft-kumar-mboned-64mcast-wkp-address-00.txt.
>
> I guess just doing IANA assignments and reserving a bit
> from 3306 are slightly separate problems, with different
> issues and uses.
>
> Finally, we also need a /96 for SSM. That can't just be
> an IANA assignment either. One interesting thing here is
> maybe that SSM is based on 3306 with plen and prefix set
> to 0. So if a bit is reserved (from 3306), then I think
> it would technically apply to SSM as well. But the SSM
> implementations I've seen (as well as a couple of RFCs)
> assume that these reserved bits are all 0. Not ignored
> as they should have been...


We just wanted to define two reserved multicast IPv6 prefixes and
after giving up modifying IP addressing architecture, we are now
talking about changing so many RFCs.

In this mail earlier Stig said:

http://www.ietf.org/mail-archive/web/mboned/current/msg01663.html

we can state that inter-domain operation is not a requirement and we
do not support embedded-RP.

Behcet