Bonjour Med, Ca va? Thank you for your deep insight and reply. When the IPv6 packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same? As defined in section 6.3 of draft-boucadair-behave-64-multicast-address-format<http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#ref-I-D.boucadair-behave-64-multicast-address-format>, "there is no need to reserve a bit in the IPv6 multicast address to separate between the translation and the encapsulation schemes." So when mPrefix64 and uPrefix64 are the same for both encapsulation and translation, mB4 could not make decision which operation to make. In this case, the IPv6 header itself can be used to identify encapsulation or translation. For example, if the next header of IPv6 header is 4, mB4 should make de-capsulation because there is IPv4 packet inside. If it is other value, translation may be needed.
Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, August 23, 2011 11:54 PM To: Tina TSOU; Jacni Qin Cc: [email protected] Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, Please see inline. Cheers, Med ________________________________ De : [email protected] [mailto:[email protected]] De la part de Tina TSOU Envoyé : mercredi 24 août 2011 04:21 À : Jacni Qin Cc : [email protected] Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Jacni, Thank you for your early reply. Have a good day. My replies are below. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Jacni Qin [mailto:[email protected]] Sent: Tuesday, August 23, 2011 6:09 PM To: Tina TSOU Cc: [email protected] Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 hi, On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU <[email protected]<mailto:[email protected]>> wrote: Hi all, Some more comments on draft-qin-softwire-dslite-multicast-04. #1 General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution? Jacni>: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective, I don't see there is necessary interaction with the unicast solution. [TT] Section 4.5 is good for the readers to understand the difference between unicast and multicast DS-Lite. I strongly suggest add some texts into this section like "the co-location of multicast elements with unicast DS-Lite elements is more deployment specific". [Med] OK. We will do. #2 Section 6.2 Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as "it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4." Jacni>:Currently, we only employ the encapsulation for date forwarding in the main text. [TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not. [Med] This excerpt from Section 6.2 explains the rule to follow: When the mB4 receives an IPv6 multicast packet, it checks whether the group address is in the range of mPrefix64 and the source address is in the range of uPrefix64. Does this answer your question?
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
