Re: draft-ietf-mboned-64-multicast-address-format

[Stig Venaas <[e-mail]>]

On 8/14/2012 9:40 AM, Behcet Sarikaya wrote:
> On Tue, Aug 14, 2012 at 4:09 AM,  <[e-mail]> wrote:
>> Dear all,
>>
>> I'm initiating this thread in the hope of understanding the
>> objections from the 6man WG and hopefully to make some progress for
>> this document.  To initiate the discussion, below are provided some
>> preliminary Q/A:
>>
>> What is the scope of this document?
>>     The document specifies an algorithmic translation of an IPv6
>>     multicast address to a corresponding IPv4 multicast address, and
>>     vice versa.  The document reserves two IPv6 multicast prefixes to
>>     be used for that purpose.
>>
>> What are these reserved prefixes?
>>     *  ff3x:0:8000::/96 for SSM
>>     *  ffxx:8000::/20 for ASM
>>
>> Does this document update IPv6 addressing architecture?
>>     No.
>>
>> Is there a unicast counterpart of this proposal?
>>     Yes, RFC6052.
>>
>> What is the problem to be solved?
>>     There are several use cases as detailed in [I-D.ietf-mboned-v4v6-
>>     mcast-ps].  In particular, the following use cases are of
>>     interest:
>>     1.  An IPv6-only receiver wants to receive multicast content from
>>         an IPv4-only source (6-4).
>>     2.  An IPv4 receiver wants to join a multicast group in IPv4
>>         domain via an IPv6-only network (4-6-4).
>>
>> Are there solutions for the unicast counterpart of these use cases?
>>     Yes; various solutions including:
>>     1.  6-4: RFC6146
>>     2.  4-6-4: RFC6333, RFC6346, ...
>
>
> I don't understand why RFC 6333 is included here.
> If you take a look at
> http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-01
> there is no need for this draft.

If I understand your draft correctly, it uses unicast for the
encapsulation, then there is no need for this.

But e.g. draft-ietf-softwire-dslite-multicast-02 needs it. If you are
using multicast encapsulation (4 in 6), you need to know which group G
or (S,G) to join at the tunnel egress point. And at the ingress, you
need to interpret the IPv6 join you receive and extract the IPv4 address
to know which IPv4 group is requested. For the latter part you could
possibly encapsulate the joins, but I think that is not so good. Anyway,
you need it for the first part.

Encapsulation is very similar to translation. The only real difference
I see, is that when you receive packets at the egress, you can just do
decap, you don't need to figure out what the addresses in the new header
should be.

Stig

> Related to this is this statement in the abstract:
>
> This
>     algorithmic translation can be used in both IPv4-IPv6 translation or
>     encapsulation schemes.
>
> I suggest removing encapsulation from the above sentence.
>
> I have concerns on the way this draft justifies these new prefixes. I
> think the justification should be completely based on translation. If
> this basis is taken, the rest of the text will flow naturally.
>
> Regards,
>
> Behcet
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>