1. Multicast Considerations for Gateway Initiated Dual-Stack lite (draft-brockners-softwire-mcast-gi-ds-lite-00) Authors: Frank Brockners (fbrockne@cisco.com), Yiu L. Lee (yiu_lee@cable.comcast.com) IETF 79, Beijing

2. Overview Multicast in Subscriber Access Networks Architectural Characteristics / Assumptions –Access Devices receive, but do not source IP-Multicast traffic –Gateway is first hop IP-Multicast router for Access Devices –Multicast and unicast forwarding paths in the access network (Access- Device to Gateway) can differ (e.g. due to use of “Multicast VLAN”) –Access network can contain IGMP proxies (to optimize Layer-2 multicast delivery) –Multicast NAT is not considered Access Device IGMP Proxy Gateway Access Device IPv4-Multicast Network IPv4-Multicast Source Deployment example

3. IP-Multicast Deployment with GI-DS-lite GI-DS-lite only applies to IPv4-Unicast traffic: IPv4-Multicast forwarding does not change –If Gateway loses IPv4-Multicast connectivity while deploying GI-DS-lite: Establish a tunnel between Gateway and appropriate IP-Multicast router –Switching to AFTR as first-hop router (e.g. in case Gateway has only IPv6 connectivity) would change multicast forwarding on Gateway and challenge AFTR & network scalability GI-DS-lite allows for overlapping IPv4 addresses on Access-Devices –Typically no additional considerations required, e.g. architectures like BBF TR-101 even contain IGMP proxies, where IGMP packets are sourced with 0.0.0.0. –For deployments with IGMPv3 and a requirement for explicit tracking, an identifier other than the Source-IPv4 address of the IGMP packets needs to be used (see also I-D.ietf-multimob-pmipv6-base-solution) Access Device IGMP Proxy Gateway Access Device IPv4-Multicast Network IP-Multicast Source AFTR Only IPv4-Unicast Deployment example

4. Next steps More feedback is much appreciated Adopt as a WG draft?