Sorry all, coming into this late. I have read the RFC and really do not get why you would want to do IPv4 to IPv6 multicast translation. Is there really multicast information that is only IPv4 capable? From everything I have used multicast for in the past, the data does not care about the IP protocol used. What is the reliance of this RFC?
Jon Steen On Friday, May 25, 2012, Bob Hinden wrote: > Med, > > On May 23, 2012, at 10:38 PM, <mohamed.boucad...@orange.com <javascript:;>> > <mohamed.boucad...@orange.com <javascript:;>> wrote: > > > Dear Bob, > > > > Yes, I read that message. It is one of reasons I added two appendixes to > explain: > > > Not seeing a response on the list, it wasn't clear to me. > > > > > * Why an Address Format is Needed for Multicast IPv4-IPv6 > Interconnection? ( > http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.1 > ) > > This just restates that you want the translator to be stateless. I > understand that. > > > * Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required? ( > http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.2 > ) > > > The issue isn't why embedding the IPv4 multicast address in the IPv6 > multicast address is needed, the issue is the way you do it. > > Appendix A2 does not address one of the alternatives I described where you > would preallocate (and register at the IANA) a group of multicast group IDs > (~ 2^^28). This would allow a 1:1 stateless mapping function. It would > avoid any changes to the IPv6 addressing architecture, and would use much > less of the IPv6 multicast address space. Your current proposal reduces > the IPv6 multicast group space by a factor of 16 in the ASM case, and a > factor of 16 million in the SSM case. This is very wasteful given you only > need to represent 2^^28 total possible IPv4 multicast groups. > > > > > You may also refer to slide 7 of > http://www.ietf.org/proceedings/83/slides/slides-83-mboned-5.pdf for the > overall approach. > > > > Could you please check the new text and let me know if it solves your > concerns? Thanks. > > My concern remains. > > Bob > > > > > Cheers > > Med > > > > > >> -----Message d'origine----- > >> De : Bob Hinden [mailto:bob.hin...@gmail.com] > >> Envoyé : mercredi 23 mai 2012 18:38 > >> À : BOUCADAIR Mohamed OLNC/NAD/TIP > >> Cc : Bob Hinden; ipv6@ietf.org > >> Objet : Re: draft-ietf-mboned-64-multicast-address-format > >> > >> Med, > >> > >> On May 23, 2012, at 6:20 AM, <mohamed.boucad...@orange.com> > >> <mohamed.boucad...@orange.com> wrote: > >> > >>> Dear all, > >>> > >>> Many thanks for the individuals who read the draft and > >> provided some comment. > >>> > >>> My read of the the answers received in this thread is there > >> is no strong reasons to question the design choices as > >> documented in the draft. > >> > >> Did you see my comments sent on 5/5/2012? I continue to think > >> that there are alternatives that do not require any change to > >> the IPv6 addressing architecture, nor use such a big > >> percentage of the multicast group ID space. > >> > >> Bob > >> > >> > >>> > >>> FWIW, I just submitted a updated version taking into account > >> the comments received during the IETF LC: > >>> > >>> * Editorial changes as suggested in SM's review > >>> * Title change (comment from C. Bormann) > >>> * Added a new section to describe the algorithm to > >> embed/extract the IPv4 address (comment from C. Bormann) > >>> * Added some pointers to documents making use of the address > >> format (comment from C. Bormann) > >>> * Added an appendix to explain why an M-bit is needed > >> (comment from C. Bormann) > >>> * Added an appendix to explain why an address format is > >> needed (comment from C. Bormann) > >>> * Added examples of means to provision the MPREFIX64 > >> (comment from C. Bormann) > >>> > >>> Diff from previous version: > >>> > >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multica > >> st-address-format-02 > >>> > >>> Cheers, > >>> Med > >>> > >>> > >>> De : ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] De > >> la part de mohamed.boucad...@orange.com > >>> Envoyé : vendredi 4 mai 2012 14:50 > >>> À : mboned-cha...@ietf.org; ipv6@ietf.org > >>> Cc : Brian Haberman; > >> draft-ietf-mboned-64-multicast-address-for...@tools.ietf.org > >>> Objet : draft-ietf-mboned-64-multicast-address-format > >>> > >>> > >>> 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-addre > >> ss-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 th -- Jon Steen 106 Apple Creek Road Frederick, MD 21702
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
