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

Dear Bob, et al.;

On Sat, May 5, 2012 at 10:12 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
> Med,
>
> On May 4, 2012, at 5:50 AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
>
>> Dear all,
>>
>> During the IETF LC for draft-ietf-mboned-64-multicast-address-format, Brian suggested to use the remaining flag instead of reserving ff3x:0:8000/33 (SSM) and ffxx:8000/17 (ASM) blocks. FYI, we have considered that approach in an early version of the document but it has been abandoned because of comments we received at that time. We recorded the rationale behind our design choice in:
>> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01#appendix-A.2.
>>
>> We are seeking more feedback from 6man and mboned on the following:
>>
>> (1) Should we maintain the current design choice
>> (2) Or adopt the suggestion from Brian?
>>
>> FWIW, discussion related to this issue can be found here: http://www.ietf.org/mail-archive/web/mboned/current/msg01508.html.
>> The latest version of the draft is available at: http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-01
>
> [personal hat on and co-author of RFC 4291]
>
> I reviewed the draft and read through the thread you referred to.
>
> I don't think the approach defined in this draft is needed nor the resulting complexity it proposes adding to the IPv6 Address Architecture.  Instead of what is proposed one could reserve a block of group ids (33 or 33 bits worth) and eliminate all of the type bits at the front.
>
> Or better yet, just keep a mapping table in the translator that maps the IPv4 multicast group to an IPv6 multicast group ID?  That wouldn't require any changes in the IPv6 multicast address.  If the purpose of these boxes is to do translation, then this should be possible, like is done with other forms of Network Address Translation (NAT).   This would also mean that you wouldn't need anything close to 2^^32 multicast groups as I suspect the number that will be used in practice will be much smaller.
>

Here is a potential way to do this that I have not seen discussed yet
for this. If it has been, my apologies and a pointer to the discussion
would be appreciated.

If DNS can be used to do "SSM Mapping" for IGMPv2  (i.e., use the
group address to create a domain name and use that to come up with an
appropriate Source address using reverse DNS lookup - see

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtssmma.html
http://www.juniper.net/techpubs/en_US/junos10.3/topics/example/multicast-ssm-mapping.html
),

then I don't see why the same trick can't be applied for IPv4 <-> IPv6
translation mappings.
This seems like the sort of thing that could be  implemented very
quickly, and does away with the need for mapping tables.

Regardless of how is it is done, I see no reason to and would be
against reserving the 4th (last) Flag in the 4291 multicast address
format for this purpose.

Regards
Marshall

> My overall conclusion is that I don't see the need for any changes to the IPv6 addressing architecture to support this application.
>
> Bob
>
>
>>
>> Your help is appreciated.
>>
>> Cheers,
>> Med
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------