Internet DRAFT - draft-boucadair-6man-64-flag-bit
draft-boucadair-6man-64-flag-bit
6man Working Group M. Boucadair, Ed.
Internet-Draft France Telecom
Intended status: Standards Track J. Qin
Expires: February 21, 2015 Cisco
Y. Lee
Comcast
S. Venaas
Cisco Systems
X. Li
CERNET Center/Tsinghua University
M. Xu
Tsinghua University
August 20, 2014
IPv6 Multicast Address With Embedded IPv4 Multicast Address
draft-boucadair-6man-64-flag-bit-01
Abstract
This document reserves one bit (M-bit) of the unicast prefix-based
multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM
mode 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
Boucadair, et al. Expires February 21, 2015 [Page 1]
Internet-Draft 64 Multicast Address Format August 2014
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 21, 2015.
Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPv4-Embedded IPv6 Multicast Prefix & Address . . . . . . . . 4
3.1. ASM Mode . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SSM Mode . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. IPv4-Embedded IPv6 Multicast Address . . . . . . . . . . 5
3.4. Address Translation Algorithm . . . . . . . . . . . . . . 6
3.5. Textual Representation . . . . . . . . . . . . . . . . . 6
3.6. Source IPv4 Address in the IPv6 Realm . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Motivations . . . . . . . . . . . . . . . . . . . . 9
A.1. Why an Address Format is Needed for Multicast IPv4-IPv6
Interconnection? . . . . . . . . . . . . . . . . . . . . 9
A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address
is Required? . . . . . . . . . . . . . . . . . . . . . . 10
A.3. Location of the IPv4 Address . . . . . . . . . . . . . . 10
Appendix B. Design Considerations . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Boucadair, et al. Expires February 21, 2015 [Page 2]
Internet-Draft 64 Multicast Address Format August 2014
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 one bit of the unicast prefix-based multicast
IPv6 address ([I-D.ietf-6man-multicast-addr-arch-update]) for Any-
Source Multicast (ASM) mode and an IPv6 multicast prefix for Source-
Specific Multicast (SSM) mode to be used in the context of IPv4-IPv6
interconnection. This document also defines how IPv4-Embedded IPv6
Multicast Addresses are constructed. Both IPv4-IPv6 translation and
encapsulation schemes can make use of this specification.
This specification can be used in conjunction with other extensions
such as embedding the rendezvous point [RFC3956]. Unicast prefix-
based and embedded-RP 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:
o IPv4-Embedded IPv6 Multicast Address: denotes a multicast IPv6
address which includes in 32 bits an IPv4 address.
o 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.4.
Boucadair, et al. Expires February 21, 2015 [Page 3]
Internet-Draft 64 Multicast Address Format August 2014
Section 3.4 specifies also how to extract an IPv4 address from an
IPv4-Embedded IPv6 Multicast Address.
o ASM_MPREFIX64: denotes a multicast Prefix64 used in Any Source
Multicast (ASM) mode.
o SSM_MPREFIX64: denotes a multicast Prefix64 used in Source
Specific Multicast (SSM) mode.
o 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. ASM Mode
The format specified in Figure 1 uses some bits defined in
[I-D.ietf-6man-multicast-addr-arch-update]: M-bit (20th bit position,
where bit 1 is the most significant bit) now has a meaning.
Details on design considerations are discussed in Appendix B.
| 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+
|11111111|ff1 |scop|ff2 | sub-group-id |v4 address|
+--------+----+----+----+-----------------------------------------+
+-+-+-+-+
ff2 (flag field 2) is a set of 4 flags: |r|r|r|M|
+-+-+-+-+
"r" bits MUST each be set to 0.
Figure 1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode
The description of the fields is as follows:
o "ff1" field is defined in
[I-D.ietf-6man-multicast-addr-arch-update].
o "scop" field is defined in [RFC3956].
o M (20th bit position): When this bit is set to 1, it indicates
that a multicast IPv4 address is embedded in the low-order 32 bits
of the multicast IPv6 address.
Boucadair, et al. Expires February 21, 2015 [Page 4]
Internet-Draft 64 Multicast Address Format August 2014
o sub-group-id: This field is configurable according to local
policies (e.g., enable embedded-RP) of the entity managing the
IPv4-IPv6 Interconnection Function. This field MUST follow the
recommendations specified in [RFC3306] if unicast-based prefix is
used or the recommendations specified in [RFC3956] if embedded-RP
is used. The default value is all zeros.
o The low-order 32 bits MUST include an IPv4 multicast address when
the M-bit is set to 1. The enclosed IPv4 multicast address SHOULD
NOT be in 232/8 range.
3.2. SSM Mode
For SSM mode, and given what is discussed in Appendix B, the
following IPv6 prefix to embed IPv4 multicast addresses is reserved:
o ff3x:0:8000::/96 ('x' is any valid scope).
3.3. 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. For SSM, MPREFIX64 MUST be
equal to ff3x:0:8000::/96. For the ASM mode, MPREFIX64 MUST have the
M-bit set to 1. Furthermore, the format of the ASM_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 2 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.
Boucadair, et al. Expires February 21, 2015 [Page 5]
Internet-Draft 64 Multicast Address Format August 2014
| 96 | 32 |
+------------------------------------------------------+----------+
| MPREFIX64 |v4 address|
+------------------------------------------------------+----------+
Figure 2: IPv4-Embedded IPv6 Multicast Address Format
3.4. Address Translation Algorithm
IPv4-Embedded IPv6 Multicast Addresses are composed according to the
following algorithm:
o 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:
o If the multicast address has the 20th bit set to 1 or it matches
ff3x:0:8000::/96 or a preconfigured MPREFIX64, extract the last 32
bits of the IPv6 multicast address.
3.5. 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.6. 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 3 provides some examples of ASM IPv4-Embedded IPv6 Address
while Figure 4 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 [RFC6676].
Boucadair, et al. Expires February 21, 2015 [Page 6]
Internet-Draft 64 Multicast Address Format August 2014
+----------------------+--------------+-----------------------------+
| MPREFIX64 | IPv4 address | IPv4-Embedded IPv6 Address |
+----------------------+--------------+-----------------------------+
| ff3x:z000:0:abc::/96 | 233.252.0.1 |ff3x:z000:0:abc::233.252.0.1 |
| ff7x:z000:0:abc::/96 | 233.252.0.2 |ff7x:z000:0:abc::233.252.0.2 |
+----------------------+--------------+-----------------------------+
where:
"x" is any valid scope
"z" is any 4 bits where the last bit is set (e.g., 1, 3, 7, ...)
Figure 3: 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 4: Example of SSM IPv4-embedded IPv6 address
5. IANA Considerations
This document requests IANA to reserve:
o ff3x:0:8000::/96 SSM 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, C.
Bormann, T. Chown, P. Koch, B. Haberman, and B. Hinden for their
comments and review.
8. References
8.1. Normative References
Boucadair, et al. Expires February 21, 2015 [Page 7]
Internet-Draft 64 Multicast Address Format August 2014
[I-D.ietf-6man-multicast-addr-arch-update]
Boucadair, M. and S. Venaas, "Updates to the IPv6
Multicast Addressing Architecture", draft-ietf-6man-
multicast-addr-arch-update-08 (work in progress), August
2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC
3956, November 2004.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
8.2. Informative References
[I-D.ietf-behave-nat64-learn-analysis]
Korhonen, J. and T. Savolainen, "Analysis of solution
proposals for hosts to learn NAT64 prefix", draft-ietf-
behave-nat64-learn-analysis-03 (work in progress), March
2012.
[I-D.ietf-mboned-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
and Q. Qiong, "IPv4-IPv6 Multicast: Problem Statement and
Use Cases", draft-ietf-mboned-v4v6-mcast-ps-04 (work in
progress), September 2013.
[I-D.ietf-softwire-dslite-multicast]
Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q.
Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients
over an IPv6 Multicast Network", draft-ietf-softwire-
dslite-multicast-07 (work in progress), March 2014.
Boucadair, et al. Expires February 21, 2015 [Page 8]
Internet-Draft 64 Multicast Address Format August 2014
[I-D.ietf-softwire-mesh-multicast]
Xu, M., Cui, Y., Wu, J., Yang, S., Metz, C., and G.
Shepherd, "Softwire Mesh Multicast", draft-ietf-softwire-
mesh-multicast-07 (work in progress), July 2014.
[I-D.ietf-softwire-multicast-prefix-option]
Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", draft-ietf-softwire-multicast-prefix-option-06
(work in progress), March 2014.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and
M. Eubanks, "Multicast Addresses for Documentation", RFC
6676, August 2012.
Appendix A. Motivations
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:
o Stateless IPv4-IPv6 header translation of multicast flows;
o Stateless IPv4-IPv6 PIM interworking function;
o Stateless IGMP-MLD interworking function (e.g., required for an
IPv4 receiver to access to IPv4 multicast content via an IPv6
network);
o Stateless (local) synthesis of IPv6 address when IPv4 multicast
address are embedded in application payload (e.g., SDP [RFC4566]);
o 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;
o Minimal operational constraints on the multicast address
management: IPv6 multicast addresses can be constructed using what
has been deployed for IPv4 delivery mode.
Boucadair, et al. Expires February 21, 2015 [Page 9]
Internet-Draft 64 Multicast Address Format August 2014
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:
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
[I-D.ietf-behave-nat64-learn-analysis] in a multicast context.
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].
Boucadair, et al. Expires February 21, 2015 [Page 10]
Internet-Draft 64 Multicast Address Format August 2014
Appendix B. Design Considerations
The following constraints should be met when reserving dedicated
prefix(es) to be used for IPv4/IPv6 multicast interconnection:
1: Belong to SSM prefix range (preferably 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 associating a meaning with
one of the reserved bits in
[I-D.ietf-6man-multicast-addr-arch-update]. Defining the 17-20
bits range to have a meaning and be used for IPv4/IPv6 transition
has the advantage of allowing for future extensions but it may be
seen as a waste of the multicast address space. Consequently,
using one of the reserved bits (in the range 17-20) from the
unicast-based IPv6 multicast address format [RFC3306] is
preferred.
Meeting (1) and (2) with the same reserved bit is not feasible
without modifying embedded-RP and unicast-based prefix
specifications; this option is avoided.
As a consequence, this document proposes to reserve a multicast
prefix for SSM and define one bit of the unicast prefix-based
multicast IPv6 address for ASM when embedding IPv4 multicast address
in an IPv6 multicast address.
Authors' Addresses
Mohamed Boucadair (editor)
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Boucadair, et al. Expires February 21, 2015 [Page 11]
Internet-Draft 64 Multicast Address Format August 2014
Jacni Qin
Cisco
China
Email: jacni@jacni.com
Yiu L. Lee
Comcast
U.S.A
Email: yiu_lee@cable.comcast.com
Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Email: stig@cisco.com
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
P.R. China
Phone: +86 10-62785983
Email: xing@cernet.edu.cn
Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: xmw@cernet.edu.cn
Boucadair, et al. Expires February 21, 2015 [Page 12]
