Re: [Int-dir] Int-Dir Review of draft-ietf-softwire-dslite-multicast-12

["Lee, Yiu" <[e-mail]>]

Hi Med and Zhen,

Actually mB4 doesn’t need to do any check. Once decap is done, it will use the standard IPv4 mcast forwarding rule. If the v4 group address is in the mroute table, it will be forwarded, if not, it will be dropped. I propose the following: 

When the mB4 receives an IP multicast packet, it MUST check the group address and the source address. If the IPv6 multicast group prefix is mPrefix64 and IPv6 source prefix is uPrefix64, the mB4 MUST decapsulate the IPv6 header. The decapsulated IPv4 multicast packet will be forwarded based on standard IPv4 multicast forwarding rule.

Thanks,
Yiu

On 12/12/16, 1:45 AM, "[e-mail]" <[e-mail]> wrote:

    >
    >b)
    >6.2.  Multicast Data Forwarding
    >   When the mB4 receives an IPv6 multicast packet, it MUST check the
    >    group address and the source address.  If the IPv6 multicast group
    >    prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4
    >    MUST decapsulate the IPv6 header and forward the IPv4 multicast
    >    packet through each relevant interface.  Otherwise, the mB4 MUST
    >    silently drop the packet.
    >comments: the mB4 not only needs to check the validity of mPrefix and
    >uPrefix, but also needs to check if there exists an associated
    >MLD/IGMP requests from that prefixes.  Only if there was an IGMP
    >report associted with this transaction, it will forward such multicast
    >packets.
    [Med] This is actually the intent of the last part of the text you quoted:  
    
       prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4
       MUST decapsulate the IPv6 header and forward the IPv4 multicast
       packet through each relevant interface. 
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    If no state is found, there won't be any "relevant interface". So the  traffic won't be forwarded.