Dear Bob, et al.; On Sat, May 5, 2012 at 10:12 PM, Bob Hinden <bob.hin...@gmail.com> wrote: > 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. >
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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
