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

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.

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
> --------------------------------------------------------------------