Med,

On May 4, 2012, at 5:50 AM, <mohamed.boucad...@orange.com> 
<mohamed.boucad...@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
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to