draft-ietf-softwire-dslite-multicast-17.txt   draft-ietf-softwire-dslite-multicast-18.txt 
Softwire WG M. Boucadair Softwire WG M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track C. Qin Intended status: Standards Track C. Qin
Expires: August 5, 2017 Cisco Expires: August 6, 2017 Cisco
C. Jacquenet C. Jacquenet
Orange Orange
Y. Lee Y. Lee
Comcast Comcast
Q. Wang Q. Wang
China Telecom China Telecom
February 1, 2017 February 2, 2017
Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6
Multicast Network Multicast Network
draft-ietf-softwire-dslite-multicast-17 draft-ietf-softwire-dslite-multicast-18
Abstract Abstract
This document specifies a solution for the delivery of IPv4 multicast This document specifies a solution for the delivery of IPv4 multicast
services to IPv4 clients over an IPv6 multicast network. The services to IPv4 clients over an IPv6 multicast network. The
solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
and uses an IPv6 multicast distribution tree to deliver IPv4 and uses an IPv6 multicast distribution tree to deliver IPv4
multicast traffic. The solution is particularly useful for the multicast traffic. The solution is particularly useful for the
delivery of multicast service offerings to DS-Lite serviced delivery of multicast service offerings to DS-Lite serviced
customers. customers.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2017. This Internet-Draft will expire on August 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 52 skipping to change at page 2, line 52
7.1. Routing Considerations . . . . . . . . . . . . . . . . . 12 7.1. Routing Considerations . . . . . . . . . . . . . . . . . 12
7.2. Processing PIM Messages . . . . . . . . . . . . . . . . . 13 7.2. Processing PIM Messages . . . . . . . . . . . . . . . . . 13
7.3. Switching from Shared Tree to Shortest Path Tree . . . . 14 7.3. Switching from Shared Tree to Shortest Path Tree . . . . 14
7.4. Multicast Data Forwarding . . . . . . . . . . . . . . . . 14 7.4. Multicast Data Forwarding . . . . . . . . . . . . . . . . 14
7.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
8.1. Other Operational Modes . . . . . . . . . . . . . . . . . 15 8.1. Other Operational Modes . . . . . . . . . . . . . . . . . 15
8.1.1. The IPv6 DR is Co-Located with the mAFTR . . . . . . 15 8.1.1. The IPv6 DR is Co-Located with the mAFTR . . . . . . 15
8.1.2. The IPv4 DR is Co-Located with the mAFTR . . . . . . 15 8.1.2. The IPv4 DR is Co-Located with the mAFTR . . . . . . 15
8.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 15 8.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 15
8.3. mAFTR Policy Configuration . . . . . . . . . . . . . . . 16 8.3. mAFTR Policy Configuration . . . . . . . . . . . . . . . 15
8.4. Static vs. Dynamic PIM Triggering . . . . . . . . . . . . 16 8.4. Static vs. Dynamic PIM Triggering . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Firewall Configuration . . . . . . . . . . . . . . . . . 16 9.1. Firewall Configuration . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Use Case: IPTV . . . . . . . . . . . . . . . . . . . 19 Appendix A. Use Case: IPTV . . . . . . . . . . . . . . . . . . . 19
Appendix B. Older Versions of Group Membership Management Appendix B. Older Versions of Group Membership Management
Protocols . . . . . . . . . . . . . . . . . . . . . 20 Protocols . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
DS-Lite [RFC6333] is an IPv4 address-sharing technique that enables DS-Lite [RFC6333] is an IPv4 address-sharing technique that enables
operators to multiplex public IPv4 addresses while provisioning only operators to multiplex public IPv4 addresses while provisioning only
IPv6 to users. A typical DS-Lite scenario is the delivery of an IPv4 IPv6 to users. A typical DS-Lite scenario is the delivery of an IPv4
service to an IPv4 user over an IPv6 network (denoted as a 4-6-4 service to an IPv4 user over an IPv6 network (denoted as a 4-6-4
scenario). [RFC6333] covers unicast services exclusively. scenario). [RFC6333] covers unicast services exclusively.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
multicast packet will be forwarded down the IPv6 multicast multicast packet will be forwarded down the IPv6 multicast
distribution tree and the mB4 will eventually receive the packet. distribution tree and the mB4 will eventually receive the packet.
The IPv6 multicast network treats the IPv4-in-IPv6 encapsulated The IPv6 multicast network treats the IPv4-in-IPv6 encapsulated
multicast packets as native IPv6 multicast packets. The IPv6 multicast packets as native IPv6 multicast packets. The IPv6
multicast routers use the outer IPv6 header to make their forwarding multicast routers use the outer IPv6 header to make their forwarding
decisions. decisions.
When the mB4 receives the IPv6 multicast packet (to G6) derived by When the mB4 receives the IPv6 multicast packet (to G6) derived by
mPrefix64, it decapsulates it and forwards the original IPv4 mPrefix64, it decapsulates it and forwards the original IPv4
multicast packet to the receivers subscribing to G4. multicast packet towards the receivers subscribing to G4.
Note: At this point, only IPv4-in-IPv6 encapsulation is defined; Note: At this point, only IPv4-in-IPv6 encapsulation is defined;
however, other types of encapsulation could be defined in the future. however, other types of encapsulation could be defined in the future.
5. IPv4/IPv6 Address Mapping 5. IPv4/IPv6 Address Mapping
5.1. Prefix Assignment 5.1. Prefix Assignment
A dedicated IPv6 multicast prefix (mPrefix64) is provisioned to the A dedicated IPv6 multicast prefix (mPrefix64) is provisioned to the
mAFTR and the mB4. The mAFTR and the mB4 use the mPrefix64 to form mAFTR and the mB4. The mAFTR and the mB4 use the mPrefix64 to form
skipping to change at page 11, line 34 skipping to change at page 11, line 34
prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4 prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4
MUST decapsulate the IPv6 header [RFC2473]; the decapsulated IPv4 MUST decapsulate the IPv6 header [RFC2473]; the decapsulated IPv4
multicast packet will be forwarded through each relevant interface multicast packet will be forwarded through each relevant interface
following standard IPv4 multicast forwarding procedure. Otherwise, following standard IPv4 multicast forwarding procedure. Otherwise,
the mB4 MUST silently drop the packet. the mB4 MUST silently drop the packet.
As an illustration, if a packet is received from source As an illustration, if a packet is received from source
2001:db8::192.0.2.33 and needs to be forwarded to group 2001:db8::192.0.2.33 and needs to be forwarded to group
ff3x:20:2001:db8::233.252.0.1, the mB4 decapsulates it into an IPv4 ff3x:20:2001:db8::233.252.0.1, the mB4 decapsulates it into an IPv4
multicast packet using 192.0.2.33 as the IPv4 source address and multicast packet using 192.0.2.33 as the IPv4 source address and
using 233.252.0.1 as the IPv4 destination multicast group. using 233.252.0.1 as the IPv4 destination multicast group. This
example assumes that the mB4 is provisioned with uPrefix64
(2001:db8::/96) and mPrefix64 (ff3x:20:2001:db8::/96).
6.3. Fragmentation 6.3. Fragmentation
Encapsulating IPv4 multicast packets into IPv6 multicast packets that Encapsulating IPv4 multicast packets into IPv6 multicast packets that
will be forwarded by the mAFTR towards the mB4 along the IPv6 will be forwarded by the mAFTR towards the mB4 along the IPv6
multicast distribution tree reduces the effective MTU size by the multicast distribution tree reduces the effective MTU size by the
size of an IPv6 header. In this specification, the data flow is size of an IPv6 header. In this specification, the data flow is
unidirectional from the mAFTR to the mB4. The mAFTR MUST fragment unidirectional from the mAFTR to the mB4. The mAFTR MUST fragment
the oversized IPv6 packet after the encapsulation into two IPv6 the oversized IPv6 packet after the encapsulation into two IPv6
packets. The mB4 MUST reassemble the IPv6 packets, decapsulate the packets. The mB4 MUST reassemble the IPv6 packets, decapsulate the
IPv6 header, and forward the IPv4 packet to the hosts that have IPv6 header, and forward the IPv4 packet to the hosts that have
subscribed to the corresponding multicast group. Further subscribed to the corresponding multicast group. Further
considerations about fragmentation issues are documented in considerations about fragmentation issues are documented in Sections
[RFC6333]. 5.3 and 6.3 of [RFC6333].
6.4. Host Built-in mB4 Function 6.4. Host Built-in mB4 Function
If the mB4 function is implemented in the host which is directly If the mB4 function is implemented in the host which is directly
connected to an IPv6-only network, the host MUST implement the connected to an IPv6-only network, the host MUST implement the
behaviors specified in Sections 6.1, 6.2, and 6.3. The host MAY behaviors specified in Sections 6.1, 6.2, and 6.3. The host MAY
optimize the implementation to provide an Application Programming optimize the implementation to provide an Application Programming
Interface (API) or kernel module to skip the IGMP-MLD Interworking Interface (API) or kernel module to skip the IGMP-MLD Interworking
Function. Optimization considerations are out of scope of this Function. Optimization considerations are out of scope of this
specification. specification.
6.5. Preserve the Scope 6.5. Preserve the Scope
When several mPrefix64s are available, if each enclosed IPv4-embedded When several mPrefix64s are available, if each enclosed IPv4-embedded
IPv6 multicast prefix has a distinct scope, the mB4 MUST select the IPv6 multicast prefix has a distinct scope, the mB4 MUST select the
appropriate IPv4-embedded IPv6 multicast prefix whose scope matches appropriate IPv4-embedded IPv6 multicast prefix whose scope matches
the IPv4 multicast address used to synthesize an IPv4-embedded IPv6 the IPv4 multicast address used to synthesize an IPv4-embedded IPv6
multicast address (Section 8 of [RFC2365]). multicast address (specific mappings are listed in Section 8 of
[RFC2365]). Mapping is achieved such that the scope of the selected
IPv6 multicast prefix does not exceed the original IPv4 multicast
scope. If the mB4 is instructed to preserve the scope but no IPv6
multicast prefix that matches the IPv4 multicast scope is found, IPv6
multicast address mapping SHOULD fail.
The mB4 MAY be configured to not preserve the scope when enforcing The mB4 MAY be configured to not preserve the scope when enforcing
the address translation algorithm. the address translation algorithm.
Consider that an mB4 is configured with two mPrefix64s Consider that an mB4 is configured with two mPrefix64s
ff0e::db8:0:0/96 (Global scope) and ff08::db8:0:0/96 (Organization ff0e::db8:0:0/96 (Global scope) and ff08::db8:0:0/96 (Organization
scope). If the mB4 receives an IGMP report from an IPv4 receiver to scope). If the mB4 receives an IGMP report from an IPv4 receiver to
subscribe to 233.252.0.1, it checks which mPrefix64 to use in order subscribe to 233.252.0.1, it checks which mPrefix64 to use in order
to preserve the scope of the requested IPv4 multicast group. In this to preserve the scope of the requested IPv4 multicast group. In this
example, given that 233.252.0.1 is intended for global use, the mB4 example, given that 233.252.0.1 is intended for global use, the mB4
skipping to change at page 14, line 48 skipping to change at page 15, line 5
ff3x:20:2001:db8::233.252.0.1 as the IPv6 destination multicast group ff3x:20:2001:db8::233.252.0.1 as the IPv6 destination multicast group
and using 2001:db8::192.0.2.33 as the IPv6 source address. and using 2001:db8::192.0.2.33 as the IPv6 source address.
7.5. Scope 7.5. Scope
The Scope field of IPv4-in-IPv6 multicast addresses should be valued The Scope field of IPv4-in-IPv6 multicast addresses should be valued
accordingly (e.g, to "E" for Global scope) in the deployment accordingly (e.g, to "E" for Global scope) in the deployment
environment. This specification does not discuss the scope value environment. This specification does not discuss the scope value
that should be used. that should be used.
Nevertheless, when several mPrefix64s are available, if each enclosed The considerations in Section 6.5 are to be followed by the mAFTR.
IPv4-embedded IPv6 multicast prefix has a distinct scope, the mAFTR
MUST select the appropriate IPv4-embedded IPv6 multicast prefix whose
scope matches the IPv4 multicast address used to synthesize an
IPv4-embedded IPv6 multicast address.
An mAFTR MAY be configured to not preserve the scope when enforcing
the address translation algorithm.
8. Deployment Considerations 8. Deployment Considerations
8.1. Other Operational Modes 8.1. Other Operational Modes
8.1.1. The IPv6 DR is Co-Located with the mAFTR 8.1.1. The IPv6 DR is Co-Located with the mAFTR
The mAFTR can embed the MLD Querier function (as well as the PIMv6 The mAFTR can embed the MLD Querier function (as well as the PIMv6
DR) for optimization purposes. When the mB4 sends a MLD Report DR) for optimization purposes. When the mB4 sends a MLD Report
message to this mAFTR, the mAFTR should process the MLD Report message to this mAFTR, the mAFTR should process the MLD Report
skipping to change at page 18, line 41 skipping to change at page 18, line 26
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>. 2016, <http://www.rfc-editor.org/info/rfc7761>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-softwire-multicast-prefix-option] [I-D.ietf-softwire-multicast-prefix-option]
Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6 Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", draft-ietf-softwire-multicast-prefix-option-12 Prefixes", draft-ietf-softwire-multicast-prefix-option-13
(work in progress), January 2017. (work in progress), February 2017.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<http://www.rfc-editor.org/info/rfc2236>. <http://www.rfc-editor.org/info/rfc2236>.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, DOI 10.17487/RFC3956, November 2004, RFC 3956, DOI 10.17487/RFC3956, November 2004,
<http://www.rfc-editor.org/info/rfc3956>. <http://www.rfc-editor.org/info/rfc3956>.
skipping to change at page 20, line 29 skipping to change at page 20, line 16
MLD Querier, or if IGMPv3 operates on the IPv4 receivers while MLDv1 MLD Querier, or if IGMPv3 operates on the IPv4 receivers while MLDv1
operates on the MLD Querier, the version mismatch issue will be operates on the MLD Querier, the version mismatch issue will be
encountered. To solve this problem, the mB4 should perform the encountered. To solve this problem, the mB4 should perform the
router portion of IGMP which is similar to the corresponding MLD router portion of IGMP which is similar to the corresponding MLD
version (IGMPv2 as of MLDv1, or IGMPv3 as of MLDv2) operating in the version (IGMPv2 as of MLDv1, or IGMPv3 as of MLDv2) operating in the
IPv6 domain. Then, the protocol interaction approach specified in IPv6 domain. Then, the protocol interaction approach specified in
Section 7 of [RFC3376] can be applied to exchange signaling messages Section 7 of [RFC3376] can be applied to exchange signaling messages
with the IPv4 receivers on which the different version of IGMP is with the IPv4 receivers on which the different version of IGMP is
operating. operating.
Note that the support of IPv4 SSM requires to enable MLDv2 in the Note that the support of IPv4 SSM requires MLDv2 to be enabled in the
IPv6 network. IPv6 network.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
 End of changes. 14 change blocks. 
23 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/