Hi Behcet, Please see inline.
Cheers, Med >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] >Envoyé : mardi 14 août 2012 18:40 >À : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : ipv6@ietf.org; Jacni Qin; >draft-ietf-mboned-64-multicast-address-for...@tools.ietf.org; >Stig Venaas >Objet : Re: draft-ietf-mboned-64-multicast-address-format > >On Tue, Aug 14, 2012 at 4:09 AM, <mohamed.boucad...@orange.com> wrote: >> Dear all, >> >> I'm initiating this thread in the hope of understanding the >> objections from the 6man WG and hopefully to make some progress for >> this document. To initiate the discussion, below are provided some >> preliminary Q/A: >> >> What is the scope of this document? >> The document specifies an algorithmic translation of an IPv6 >> multicast address to a corresponding IPv4 multicast address, and >> vice versa. The document reserves two IPv6 multicast prefixes to >> be used for that purpose. >> >> What are these reserved prefixes? >> * ff3x:0:8000::/96 for SSM >> * ffxx:8000::/20 for ASM >> >> Does this document update IPv6 addressing architecture? >> No. >> >> Is there a unicast counterpart of this proposal? >> Yes, RFC6052. >> >> What is the problem to be solved? >> There are several use cases as detailed in [I-D.ietf-mboned-v4v6- >> mcast-ps]. In particular, the following use cases are of >> interest: >> 1. An IPv6-only receiver wants to receive multicast content from >> an IPv4-only source (6-4). >> 2. An IPv4 receiver wants to join a multicast group in IPv4 >> domain via an IPv6-only network (4-6-4). >> >> Are there solutions for the unicast counterpart of these use cases? >> Yes; various solutions including: >> 1. 6-4: RFC6146 >> 2. 4-6-4: RFC6333, RFC6346, ... > > >I don't understand why RFC 6333 is included here. Med: RFC6333 is provided as an example of a unicast solution for the 4-6-4 case. >If you take a look at >http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-01 >there is no need for this draft. Med: Yes, because you are using unicast not multicast capabilities between the AFTR and the CPE. The solution adopted in softwire (http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/) makes use of native multicast capabilities to deliver IPv4 content over an IPv6 network. > >Related to this is this statement in the abstract: > >This > algorithmic translation can be used in both IPv4-IPv6 translation or > encapsulation schemes. > >I suggest removing encapsulation from the above sentence. Med: The algorithmic translation is about address translation not the way packets are constructed...which applies for both encap and translation. Specific solutions design is out of scope. > >I have concerns on the way this draft justifies these new prefixes. I >think the justification should be completely based on translation. If >this basis is taken, the rest of the text will flow naturally. > >Regards, > >Behcet > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
