[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                        B. Sarikaya
Internet-Draft                                                Huawei USA
Intended status: Standards Track                           June 21, 2012
Expires: December 23, 2012


                 Multicast Support for Dual Stack Lite
             draft-sarikaya-softwire-dslitemulticast-01.txt

Abstract

   This memo specifies modifications required to Dual-Stack Lite (DS-
   Lite) so that both IPv4 hosts can receive multicast data from IPv4
   servers.

   The DS-Lite solution is based on DS-Lite Basic Bridging BroadBand
   element (B4) proxying Internet Group Management Protocol (IGMP) and
   then tunneling IGMP messages over IPv4-in-IPv6 softwire to DS-Lite
   Address Family Transition Router element (AFTR).  IPv4 multicast data
   received at AFTR is tunneled over IPv4-in-IPv6 softwire to B4 and
   then delivered to the hosts.  This solution integrates well with DS-
   Lite unicast solution by using IPv4-in-IPv6 softwire and works with
   unicast IPv6 network connecting B4 with AFTR.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 23, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Sarikaya                Expires December 23, 2012               [Page 1]


Internet-Draft        Multicast Support for DS-Lite            June 2012


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  DS-Lite Multicast Operation  . . . . . . . . . . . . . . . . .  4
     5.1.  Tunnel Interface Considerations  . . . . . . . . . . . . .  6
   6.  Multicast Support for Host-Based Architecture  . . . . . . . .  7
   7.  Avalanche Problem  . . . . . . . . . . . . . . . . . . . . . .  7
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  8
     10.2. Informative references . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10


























Sarikaya                Expires December 23, 2012               [Page 2]


Internet-Draft        Multicast Support for DS-Lite            June 2012


1.  Introduction

   With IPv4 address depletion on the horizon, many techniques are being
   standardized for IPv6 migration including DS-Lite [RFC6333] and 6rd
   [RFC5969].  DS-Lite enables IPv4 hosts to communicate with external
   hosts using IPv6 only network and moves the traditional NAT to the
   network.  B4 element's LAN side is dual stack and WAN side is IPv6
   only.  B4 tunnels IPv4 packets received from the LAN side to AFTR
   element after encapsulating IPv4 packet in an IPv6 packet.  AFTR
   decapsulates the packet, does a NAT operation and then sends the
   packet out to IPv4 public internet.

   DS-Lite as defined in [RFC6333] is unicast only, it does not support
   multicast.  In this document we specify multicast extensions to DS-
   Lite in order to provide IP multicast communication to home IPv4
   users in DS-Lite.


2.  Terminology

   This document uses the terminology defined in [RFC6333] and
   [RFC3376].


3.  Requirements

   This section states requirements on DS-Lite multicast support
   protocol.

   DS-Lite multicast solution MUST integrate with DS-Lite unicast
   solution, it MUST not introduce additional mechanisms to the existing
   B4 to AFTR communication.

   DS-Lite multicast solution MUST not require additional capabilities
   in IPv6 network connecting B4 to AFTR other than what unicast DS-Lite
   solution requires.

   DS-Lite B4 MUST support IGMP Proxy as defined in [RFC4605].  DS-Lite
   B4 MAY support MLD Proxy.

   DS-Lite AFTR MUST support IGMP Querrier.  DS-Lite AFTR MAY support
   MLD Querrier.

   Both any source multicast (ASM) and source specific multicast (SSM)
   MUST be supported.






Sarikaya                Expires December 23, 2012               [Page 3]


Internet-Draft        Multicast Support for DS-Lite            June 2012


4.  Architecture

   In DS-Lite, there are hosts (possibly IPv4/ IPv6 dual stack) served
   by B4 element.  B4 is dual stack facing the hosts and IPv6 only
   facing the network or WAN side.  At the boundary of the network there
   is AFTR.  AFTR receives IPv4 packets tunneled in IPv6 from B4 and
   decapsulates them and sends them out to IPv4 network.

   In order to support multicast communication B4 implements IGMP Proxy
   function [RFC4605].  IPv4 hosts send their join requests (IGMP
   Membership Report messages) to B4.  B4 as a proxy sends aggregated
   Report messages upstream towards AFTR.

   AFTR is the default multicast querier for B4.  AFTR implements
   multicast router function or it could be another IGMP proxy.

   All the elements of DS-Lite multicast support system are shown in
   Figure 1.


           Dual Stack Hosts                                   IPv4
                  +----+                                      Network
                  | H1 |                 IPv6
                  +----+      +-----+    only       +-------+     +
                  +----+      | B4  |    network -- |  AFTR |
                  | H2 |   ---| IGMP|--- IPv4-in-   |  IGMP |    IPv6
                  +----+      |Proxy|    IPv6       |Querier|   Network
                  +----+      +-----+    tunnel     +-------+
                  | H3 |
                  +----+



           Figure 1: Architecture of DS-Lite Multicast Protocol


5.  DS-Lite Multicast Operation

   In this section we specify how the host can subscribe and receive
   IPv4 multicast data from IPv4 content providers based on the
   architecture defined in Section 4.

   The hosts will send their subscription requests for IPv4 multicast
   groups upstream to the default router, i.e.  B4 Element.  After
   subscribing to the group, the host can receive multicast data from
   the B4.  The host implements IGMP protocol's host part.

   In order to support SSM, IGMPv3 MUST be supported by the host, B4 and



Sarikaya                Expires December 23, 2012               [Page 4]


Internet-Draft        Multicast Support for DS-Lite            June 2012


   AFTR.

   B4 Element is IGMP Proxy.  After receiving the first IGMP Report
   message requesting subscription to an IPv4 multicast group, B4
   establishes a tunnel interface with a AFTR.  The tunnel is IPv6 based
   but it will carry IPv4 traffic, IGMP messages back and forth and IPv4
   multicast data messages downstream.  This is similar to [RFC6224]
   Section 4.4 but the operation is much simpler.  In DS-Lite
   environment there is no requirement to handle host mobility.  B4 does
   not have to keep more than one tunnel interfaces, a single interface
   is sufficient.  IGMP Proxy at the B4 does not have to have more than
   one proxy instances, a single instance is sufficient.

   B4 is regular IGMP proxy and it keeps IGMP proxy membership database.
   B4 inserts multicast forwarding state on the incoming interface, and
   merges state updates into the IGMP proxy membership database.  B4
   updates or removes elements from the database as required.  B4 will
   then send an aggregated Report via the upstream tunnel to the AFTR
   when the membership database changes.

   B4 answers IGMP queries from AFTR based on the membership database.
   B4's downstream link follows the traditional multipoint channel
   forwarding and does not pose any specific problems.

   B4 receives IPv4 multicast data from the AFTR tunneled over the
   tunnel interface.  B4 decapsulates the packet and then forwards it
   downstream.  Each member host receives the data packet based on Layer
   2 multicast interface.  No packet duplication is necessary.

   AFTR acts as the as the default multicast querier for all B4s that
   have established an IPv6 tunnel with it.  In order to keep a
   consistent multicast state between a B4 and AFTR, once a B4 is
   connected it will stay connected until the state becomes empty.
   After that point, the B4 may continue to use the tunnel for IPv4
   unicast traffic.

   According to aggregated IGMP reports received from a B4, AFTR
   establishes group/source-specific multicast forwarding states at its
   corresponding downstream tunnel interfaces.  After that, AFTR
   maintains or removes the state as required by the aggregated reports
   received from B4.

   At the upstream interface, AFTR procures for aggregated multicast
   membership maintenance.  Based on the multicast-transparent
   operations of the B4s, the AFTR treats its tunnel interfaces as
   multicast enabled downstream links, serving zero to many listening
   nodes.




Sarikaya                Expires December 23, 2012               [Page 5]


Internet-Draft        Multicast Support for DS-Lite            June 2012


   Multicast traffic arriving at the AFTR is transparently forwarded
   according to its multicast forwarding information base.  Multicast
   data is first replicated and then forwarded in IPv4-in-IPv6 tunnel
   from AFTR to the corresponding B4.

5.1.  Tunnel Interface Considerations

   Legacy IPv4 in IPv6 tunneling is performed as in [RFC2473] and
   [RFC4213].  Considerations specified in [RFC6333] apply.  Packets
   upstream from B4 carry only IGMP signaling messages and they are not
   expected to fragmentation.  However packets downstream, i.e.
   multicast data to B4 may be subject to fragmentation.

   Source and destination addresses of IGMP messages in IPv4-in-IPv6
   softwire from B4 is as follows:

   Source address of IPv6 header is B4 IPv6 address, e.g.
   2001:db8:0:1::1, destination address is AFTR address, e.g. 2001:db8:
   0:2::1.

   Source address of IGMP messages is B4's IPv4 interface address, e.g.
   192.0.0.2, destination address is the all-systems multicast address
   of 224.0.0.1 for IGMP Query, all IGMPv3-capable multicast routers of
   224.0.0.22 for IGMPv3 Report, the multicast group specified in the
   Group Address field of the Report for IGMPv1 or IGMPv2 Report.

   Source and destination addresses of IGMP messages in IPv4-in-IPv6
   softwire from AFTR is as follows:

   Source address of IPv6 header is AFTR address, e.g. 2001:db8:0:2::1,
   destination address is B4 IPv6 address, e.g. 2001:db8:0:1::1.

   Source address of IGMP messages is AFTR's IPv4 interface address,
   e.g. 192.0.2.1, destination address is the all-systems multicast
   address of 224.0.0.1 for IGMP Query, all IGMPv3-capable multicast
   routers of 224.0.0.22 for IGMPv3 Report, the multicast group
   specified in the Group Address field of the Report for IGMPv1 or
   IGMPv2 Report.

   Source and destination addresses of multicast data messages in IPv4-
   in-IPv6 softwire is as follows:

   Source address of IPv6 header is AFTR address, e.g. 2001:db8:0:2::1,
   destination address is B4 IPv6 address, e.g. 2001:db8:0:1::1.

   Source address of IPv4 multicast data is unicast IPv4 address of the
   multicast source, e.g. the content provider, destination address is
   IPv4 multicast group address.



Sarikaya                Expires December 23, 2012               [Page 6]


Internet-Draft        Multicast Support for DS-Lite            June 2012


   AFTR decapsulates datagrams carrying IGMP messages from B4's and then
   IGMP router processing takes over.  Network Address Translation (NAT)
   is not applied on IGMP messages.


6.  Multicast Support for Host-Based Architecture

   In this section we specify multicast support for Host-Based DS-Lite
   architecture described in Appendix B2 of [RFC6333].

   In host-based DS-Lite, the host accesses the service provider network
   directly with an IPv6 global address.  Host sends its IPv4 datagrams
   in IPv6 using an IPv4-in-IPv6 softwire tunnel to an AFTR, i.e. it
   implements DS-Lite B4.  Source address of all IPv4 datagrams is the
   pre-configured well-known IPv4 non-routable address.

   For multicast, there are two choices: the host could implement host
   side of IGMP protocol or for mobile router type of hosts, the host
   implements IGMP proxy as in Section 5.

   Host encapsulates IGMP messages as described in Section 5.1 and sends
   them to AFTR.  AFTR does not perform IPv4-IPv4 NAT translations on
   IGMP datagrams instead they are processed by IGMP router at the AFTR.

   Multicast data received from AFTR for a multicast group that the host
   has subscribed is decapsulated by the host, if the host is IGMP
   client, it processes the data.  If the host is IGMP proxy, it
   consults multicast state for the group and forwards the data
   downstream so that the members can receive the data.


7.  Avalanche Problem

   When multicast datagrams are received at the AFTR, AFTR consults its
   memebership database and duplicates the packets for each member B4
   interface and then these datagrams are forwarded in IPv4-in-IPv6
   softwire downstream.  This may cause an avalanche of downstream
   packets if the number of member B4's is high.

   Avalanche problem can be eased by network partitioning.  AFTR can be
   deployed closer to the users.  For example in broadband networks,
   AFTR can be deployed at the Broadband Network Gateway (BNG) nodes.


8.  IANA Considerations

   None.




Sarikaya                Expires December 23, 2012               [Page 7]


Internet-Draft        Multicast Support for DS-Lite            June 2012


9.  Acknowledgements

   TBD.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in Proxy Mobile
              IPv6 (PMIPv6) Domains", RFC 6224, April 2011.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

10.2.  Informative references

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

   [RFC4286]  Haberman, B. and J. Martin, "Multicast Router Discovery",
              RFC 4286, December 2005.

   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,



Sarikaya                Expires December 23, 2012               [Page 8]


Internet-Draft        Multicast Support for DS-Lite            June 2012


              "Considerations for Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) Snooping
              Switches", RFC 4541, May 2006.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.













































Sarikaya                Expires December 23, 2012               [Page 9]


Internet-Draft        Multicast Support for DS-Lite            June 2012


Author's Address

   Behcet Sarikaya
   Huawei USA
   5340 Legacy Drive Building 175
   Plano, TX  75074

   Phone:
   Email: sarikaya@ieee.org










































Sarikaya                Expires December 23, 2012              [Page 10]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/