IPv6 Multicast Address With Embedded IPv4 Multicast Address
draft-ietf-mboned-64-multicast-address-format-03

Abstract

This document reserves two IPv6 multicast prefixes to be used in the context of IPv4-IPv6 interconnection. The document specifies an algorithmic translation of an IPv6 multicast address to a corresponding IPv4 multicast address, and vice versa. This algorithmic translation can be used in both IPv4-IPv6 translation or encapsulation schemes.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

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 February 09, 2013.

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 (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
• 2. Terminology
• 3. IPv4-Embedded IPv6 Multicast Prefix & Address
• 3.1. Reserving Dedicated Prefixes
• 3.2. IPv4-Embedded IPv6 Multicast Address
• 3.3. Address Translation Algorithm
• 3.4. Textual Representation
• 3.5. Source IPv4 Address in the IPv6 Realm
• 4. Examples
• 5. IANA Considerations
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Motivations
• Appendix A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 Interconnection?
• Appendix A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required?
• Appendix A.3. Location of the IPv4 Address
• Authors' Addresses

1. Introduction

Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast], [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow access to IPv4 multicast content from hosts attached to IPv6-enabled domains. Even if these solutions have distinct applicability scopes (translation vs. encapsulation) and target different use cases, they all make use of specific IPv6 multicast addresses to embed an IPv4 multicast address. Particularly, the IPv4-embedded IPv6 multicast address is used as a destination IPv6 address of multicast flows received from an IPv4-enabled domain and injected by the IPv4-IPv6 Interconnection Function into an IPv6-enabled domain. It is also used to build an IPv6 multicast state (*, G6) or (S6, G6) corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the IPv4-IPv6 Interconnection Function. [I-D.ietf-mboned-v4v6-mcast-ps] provides more discussion about issues related to IPv4/IPv6 multicast.

This document reserves two prefixes to be used to synthesize IPv4-embedded IPv6 multicast address. This document also defines how IPv4-embedded IPv6 multicast addresses are constructed. Both IPv4-IPv6 translation or encapsulation schemes can make use of these prefixes.

Appendix Appendix A.1 enumerates the arguments in favor of reserving dedicated prefixes Appendix Appendix A.2 discusses why identifying an IPv4-embedded IPv6 multicast address is needed.

This specification can be used in conjunction with other extensions such as building unicast prefix-based multicast IPv6 address [RFC3306] or embedding the rendezvous point [RFC3956]. These techniques are important tools to simplify IPv6 multicast deployments. Indeed, unicast prefix-based IPv6 addressing is used in many current IPv6 multicast deployments, and has also been defined for IPv4, and is seen as a very useful technique. Also embedded-RP is used in existing deployments.

This document is a companion document to [RFC6052] which focuses exclusively on IPv4-embedded IPv6 unicast addresses.

2. Terminology

This document makes use of the following terms:

• IPv4-embedded IPv6 multicast address: denotes a multicast IPv6 address which includes in 32 bits an IPv4 address.
• Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6 multicast prefix to be used to construct IPv4-embedded IPv6 multicast addresses. This prefix is used to build an IPv4-embedded IPv6 multicast address as defined in Section 3.3. Section 3.3 specifies also how to extract an IPv4 address from an IPv4-embedded IPv6 multicast address.
• ASM_MPREFIX64: denotes a multicast Prefix64 used in Any Source Multicast (ASM) mode.
• SSM_MPREFIX64: denotes a multicast Prefix64 used in Source Specific Multicast (SSM) mode.
• IPv4-IPv6 Interconnection Function: refers to a function which is enabled in a node interconnecting an IPv4-enabled domain with an IPv6-enabled one. It can be located in various places of the multicast network. Particularly, in terms of multicast control messages, it can be an IGMP/MLD Interworking Function or an IPv4-IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection Function is configured with one or two MPREFIX64s.

3. IPv4-Embedded IPv6 Multicast Prefix & Address

3.1. Reserving Dedicated Prefixes

The following constraints should be met when reserving dedicated prefix(es) to be used for IPv4/IPv6 multicast interconnection:

1:

Belong to ff3x::/32 and be compatible with unicast-based prefix [RFC3306] for SSM. Note that [RFC3306] suggests to set "plen" to 0 and "network-prefix" to 0. As such, any prefix in the 33-96 range can be convenient. Given [RFC4607] indicates future specifications may allow a non-zero network prefix field, a /33 would allow for future extensions but it has the drawback of reserving a large block. A /96 would be adequate for the use cases already identified in [I-D.ietf-mboned-v4v6-mcast-ps]. In the event of any concrete extension, reserving additional prefixes may be considered.

2:

Be compatible with embedded-RP [RFC3956] and unicast-based prefix [RFC3306] for ASM. This results in a prefix length to be in the 17-20 range. A /17 has the advantage of allowing for future extensions but it may be seen as a waste of the multicast address space. Consequently, a /20 is preferred.

3:

Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for IANA.

Meeting (1) and (2) with the same prefix is not feasible without modifying embedded-RP and unicast-based prefix specifications; this option is avoided.

As a consequence, two multicast prefixes are proposed to be used when embedding IPv4 address: one prefix for ASM and another one for the SSM. This document reserves the following multicast prefixes to be used in the context of IPv4/IPv6 multicast interconnection:

• ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address in the last 32 bits.
• ffxx:8000::/20 ASM range to embed an IPv4 multicast address in the last 32 bits.

3.2. IPv4-Embedded IPv6 Multicast Address

For the delivery of the IPv4-IPv6 multicast interconnection services, a dedicated multicast prefix denoted as MPREFIX64 should be provisioned (e.g., using NETCONF or [I-D.ietf-softwire-multicast-prefix-option]) to any function requiring to build an IPv4-embedded IPv6 multicast address based on an IPv4 multicast address. MPREFIX64 can be of ASM or SSM type. When both modes are used, two prefixes are required to be provisioned.

The length of MPREFIX64 MUST be /96. MPREFIX64 should belong to ffxx:8000::/20 for ASM mode and ff3x:0:8000::/96 for the SSM mode.

For the ASM mode, the format of the MPREFIX64 should follow what is specified in [RFC3306] and [RFC3956] if corresponding mechanisms are used. If not, bits 21-96 can be set to any value.

Figure 1 shows how to build an IPv4-embedded IPv6 multicast address using a configured MPREFIX64 and an IPv4 multicast address. The low-order 32 bits MUST include an IPv4 multicast address. The enclosed IPv4 multicast address SHOULD NOT be in 232/8 range if an ASM_PREFIX64 is configured. The enclosed IPv4 multicast address SHOULD be in 232/8 range if an SSM_PREFIX64 is configured.

Embedding an IPv4 multicast address in the last 32 bits does not conflict with the Group IDs assigned by IANA (i.e., 0x00000001 to 0x3FFFFFFF [RFC3307]).

When several MPREFIX64 are available, it is RECOMMENDED to use the MPREFIX64 which preserve the scope of the IPv4 multicast address.

|                             96                       |    32    |
+------------------------------------------------------+----------+
|                         MPREFIX64                    |v4 address|
+------------------------------------------------------+----------+

Figure 1: IPv4-Embedded IPv6 Multicast Address Format

3.3. Address Translation Algorithm

IPv4-embedded IPv6 multicast addresses are composed according to the following algorithm:

• Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to obtain a 128-bit address.

The IPv4 multicast addresses are extracted from the IPv4-embedded IPv6 multicast addresses according to the following algorithm:

• If the multicast address belongs to ff3x:0:8000::/96 or ffxx:8000::/20, extract the last 32 bits of the IPv6 multicast address.

3.4. Textual Representation

The embedded IPv4 address in an IPv6 multicast address is included in the last 32 bits; therefore dotted decimal notation can be used.

3.5. Source IPv4 Address in the IPv6 Realm

An IPv4 source is represented in the IPv6 realm with its IPv4-converted IPv6 address [RFC6052].

4. Examples

Figure 2 provides an example of ASM IPv4-Embedded IPv6 Address while Figure 3 provides an example of SSM IPv4-Embedded IPv6 Address.

IPv4 multicast addresses used in the examples are derived from the IPv4 multicast block reserved for documentation in [I-D.ietf-mboned-mcaddrdoc].

 +---------------------+--------------+----------------------------+
 |      MPREFIX64      | IPv4 address | IPv4-embedded IPv6 address |
 +---------------------+--------------+----------------------------+
 | ffxx:8000:0:abc::/96|  233.252.0.1 |ffxx:8000:0:abc::233.252.0.1|
 +---------------------+--------------+----------------------------+

Figure 2: Example of ASM IPv4-embedded IPv6 address

 +---------------------+--------------+----------------------------+
 |      MPREFIX64      | IPv4 address | IPv4-embedded IPv6 address |
 +---------------------+--------------+----------------------------+
 |   ff3x:0:8000::/96  | 233.252.0.5  |   ff3x:0:8000::233.252.0.5 |
 +---------------------+--------------+----------------------------+

Figure 3: Example of SSM IPv4-embedded IPv6 address

5. IANA Considerations

Authors of this document request to reserve:

• ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address in the last 32 bits.
• ffxx:8000::/20 ASM range to embed an IPv4 multicast address in the last 32 bits.

6. Security Considerations

This document defines an algorithmic translation of an IPv6 multicast address into an IPv4 multicast address, and vice versa. The security considerations discussed in [RFC6052] are to be taken into consideration.

7. Acknowledgements

Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou and C. Bormann for their comments and review.

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Motivations

Appendix A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 Interconnection?

Arguments why an IPv6 address format is needed to embed multicast IPv4 address are quite similar to those of [RFC6052]. Concretely, the definition of a multicast address format embedding a multicast IPv4 address allows:

• Stateless IPv4-IPv6 header translation of multicast flows;
• Stateless IPv4-IPv6 PIM interworking function;
• Stateless IGMP-MLD interworking function (e.g., required for an IPv4 receiver to access to IPv4 multicast content via an IPv6 network);
• Stateless (local) synthesis of IPv6 address when IPv4 multicast address are embedded in application payload (e.g., SDP [RFC4566]);
• Except the provisioning of the same MPREFIX64, no coordination is required between IPv4-IPv6 PIM interworking function, IGMP-MLD interworking function, IPv4-IPv6 Interconnection Function and any ALG (Application Level Gateway) in the path;
• Minimal operational constraints on the multicast address management: IPv6 multicast addresses can be constructed using what has been deployed for IPv4 delivery mode.

Appendix A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required?

Reserving a dedicated multicast prefix for IPv4-IPv6 interconnection purposes is a means to guide the address selection process at the receiver side; in particular it assists the receiver to select the appropriate IP multicast address while avoiding to involve an IPv4-IPv6 interconnection function in the path.

Two use cases to illustrate this behavior are provided below:[I-D.ietf-behave-nat64-learn-analysis] in a multicast context.

1. An ALG is required to help an IPv6 receiver to select the appropriate IP address when only the IPv4 address is advertised (e.g., using SDP); otherwise the access to the IPv4 multicast content can not be offered to the IPv6 receiver. The ALG may be located downstream the receiver. As such, the ALG does not know in advance whether the receiver is dual-stack or IPv6-only. The ALG may be tuned to insert both the original IPv4 address and corresponding IPv6 multicast address. If a dedicated prefix is not used, a dual-stack receiver may prefer to use the IPv6 address to receive the multicast content. This address selection would require multicast flows to cross an IPv4-IPv6 interconnection function.
2. In order to avoid involving an ALG in the path, an IPv4-only source can advertise both its IPv4 address and IPv4-embedded IPv6 multicast address. If a dedicated prefix is not reserved, a dual-stack receiver may prefer to use the IPv6 address to receive the multicast content. This address selection would require multicast flows to cross an IPv4-IPv6 interconnection function.

Reserving dedicated IPv6 multicast prefixes for IPv4-IPv6 interconnection purposes mitigates the issues discussed in

Appendix A.3. Location of the IPv4 Address

There is no strong argument to allow for flexible options to encode the IPv4 address inside the multicast IPv6 address. The option retained by the authors is to encode the multicast IPv4 address in the low-order 32 bits of the IPv6 address.

This choice is also motivated by the need to be compliant with [RFC3306] and [RFC3956].

Authors' Addresses