Softwire WG M. Boucadair
Internet-Draft Orange
Intended status: Standards Track J. Qin
Expires: December 15, 2016 Cisco
T. Tsou
Philips Lighting
X. Deng
The University of New South Wales
June 13, 2016
DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes
draft-ietf-softwire-multicast-prefix-option-11
Abstract
This document defines a Dynamic Host Configuration Protocol version 6
(DHCPv6) Option for multicast IPv4 service continuity solutions,
which is used to carry the IPv6 prefixes to be used to build unicast
and multicast IPv4-embedded IPv6 addresses.
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 15, 2016.
Copyright Notice
Copyright (c) 2016 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
Boucadair, et al. Expires December 15, 2016 [Page 1]
Internet-Draft IPv4/IPv6 Multicast Prefixes Option June 2016
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. PREFIX64 DHCPv6 Option . . . . . . . . . . . . . . . . . . . 3
4. Configuration Guidelines for the Server . . . . . . . . . . . 5
5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Several solutions (e.g., [I-D.ietf-softwire-dslite-multicast]) are
proposed for the delivery of multicast services in the context of
transition to IPv6. Even if these solutions may have different
applicable use cases, they all use specific IPv6 addresses that embed
IPv4 addresses, for both multicast group and source addresses.
This document defines a DHCPv6 option [RFC3315] that carries the IPv6
prefixes to be used for constructing these IPv4-embedded IPv6
addresses.
In particular, this option can be used in the context of DS-Lite
[RFC6333], Stateless A+P [RFC6346], and other IPv4-IPv6 transition
techniques.
1.1. 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].
2. Terminology
This document makes use of the following terms:
Boucadair, et al. Expires December 15, 2016 [Page 2]
Internet-Draft IPv4/IPv6 Multicast Prefixes Option June 2016
IPv4-embedded IPv6 address: an IPv6 address which embeds a 32 bit-
encoded IPv4 address [RFC6052]. An IPv4-embedded IPv6 address can
be a unicast or a multicast address.
PREFIX64: is an IPv6 prefix used for synthesizing IPv4-embedded IPv6
addresses. A PREFIX64 can be of unicast or multicast.
Note: "64" is used as an abbreviation for IPv6-IPv4
interconnection.
ASM_PREFIX64: a multicast PREFIX64 which belongs to the Any-Source
Multicast (ASM) range.
SSM_PREFIX64: a multicast PREFIX64 which belongs to the Source-
Specific Multicast (SSM) [RFC4607]) range.
U_PREFIX64: a unicast PREFIX64 for building the IPv4-embedded IPv6
addresses of multicast sources in SSM mode.
3. PREFIX64 DHCPv6 Option
OPTION_V6_PREFIX64 (Figure 1) conveys the IPv6 prefix(es) to be used
(e.g., by an mB4 [I-D.ietf-softwire-dslite-multicast]) to synthesize
IPv4-embedded IPv6 addresses.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_PREFIX64 | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| asm-length | |
+-+-+-+-+-+-+-+-+ :
: ASM_PREFIX64 (Variable) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ssm-length | |
+-+-+-+-+-+-+-+-+ :
: SSM_PREFIX64 (Variable) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast-length| |
+-+-+-+-+-+-+-+-+ :
: U_PREFIX64 (Variable) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DHCPv6 Option Format for PREFIX64
The fields of the option shown in Figure 1 are as follows:
option-code: OPTION_V6_PREFIX64 (see Section 8).
Boucadair, et al. Expires December 15, 2016 [Page 3]
Internet-Draft IPv4/IPv6 Multicast Prefixes Option June 2016
option-length: length of the PREFIX64 option.
asm-length: the prefix-length for the ASM IPv4-embedded prefix, as
an 8-bit unsigned integer (0 to 128). This field represents the
number of valid leading bits in the prefix.
ASM_PREFIX64: this field identifies the IPv6 multicast prefix to be
used to synthesize the IPv4-embedded IPv6 addresses of the
multicast groups in the ASM mode. It is a variable size field
with the length of the field defined by the asm-length field and
is rounded up to the nearest octet boundary. In this case, any
additional padding bits must be zeroed. The conveyed multicast
IPv6 prefix MUST belong to the ASM range.
ssm-length: the prefix-length for the SSM IPv4-embedded prefix, as
an 8-bit unsigned integer (0 to 128). This field represents the
number of valid leading bits in the prefix.
SSM_PREFIX64: this field identifies the IPv6 multicast prefix to be
used to synthesize the IPv4-embedded IPv6 addresses of the
multicast groups in the SSM mode. It is a variable size field
with the length of the field defined by the ssm-length field and
is rounded up to the nearest octet boundary. In such case any
additional padding bits must be zeroed. The conveyed multicast
IPv6 prefix MUST belong to the SSM range.
unicast-length: the prefix-length for the IPv6 unicast prefix to be
used to synthesize the IPv4-embedded IPv6 addresses of the
multicast sources, as an 8-bit unsigned integer (0 to 128). This
field represents the number of valid leading bits in the prefix.
U_PREFIX64: this field identifies the IPv6 unicast prefix to be used
in SSM mode for constructing the IPv4-embedded IPv6 addresses
representing the IPv4 multicast sources in the IPv6 domain.
U_PREFIX64 may also be used to extract the IPv4 address from the
received multicast data flows. It is a variable size field with
the length of the field defined by the unicast-length field and is
rounded up to the nearest octet boundary. In this case, any
additional padding bits must be zeroed. The address mapping MUST
follow the guidelines documented in [RFC6052].
Note that it was tempting to define three distinct DHCPv6 options,
but that approach was not adopted because it has a side effect: the
specification of a DHCPv6 option that could be used to discover
unicast PREFIX64s in environments where multicast is not enabled.
Such side effect conflicts with the recommendation documented in
Section 6 of [RFC7051].
Boucadair, et al. Expires December 15, 2016 [Page 4]
Internet-Draft IPv4/IPv6 Multicast Prefixes Option June 2016
4. Configuration Guidelines for the Server
DHCP servers supporting OPTION_V6_PREFIX64 should be configured with
U_PREFIX64 and at least one multicast PREFIX64 (i.e., ASM_PREFIX64
and/or SSM_PREFIX64).
When a multicast PREFIX64 (ASM_PREFIX64 or SSM_PREFIX64) is
configured, the length of the prefix must be /96.
Both ASM_PREFIX64 and SSM_PREFIX64 may be configured and therefore be
returned to a requesting DHCP client in the same OPTION_V6_PREFIX64.
In particular, if both SSM and ASM modes are supported, ASM_PREFIX64
and SSM_PREFIX64 prefixes must be configured. For SSM deployments,
both SSM_PREFIX64 and U_PREFIX64 must be configured.
When distinct IPv6 multicast address scopes [RFC7346] are required to
preserve the scope when translating IPv4 multicast addresses
(Section 8 of [RFC2365]), each scope is configured as a separate
OPTION_V6_PREFIX64. How DHCP servers are configured to separate
multicast PREFIX64 per scope is implementation-specific and not
covered by this document.
When scope preservation is not required, only one instance of
OPTION_V6_PREFIX64 is configured.
5. DHCPv6 Client Behavior
To retrieve the IPv6 prefixes that will be used to synthesize unicast
and multicast IPv4-embedded IPv6 addresses, the DHCPv6 client MUST
include OPTION_V6_PREFIX64 in its OPTION_ORO. If the DHCPv6 client
receives more than one OPTION_V6_PREFIX64 option from the DHCPv6
server:
o If each enclosed IPv6 multicast prefix has a distinct scope, the
client MUST select the appropriate IPv6 multicast prefix whose
scope matches the IPv4 multicast address used to synthesize an
IPv4-embedded IPv6 multicast address.
o If at least two of the received options convey IPv6 multicast
prefixes that have the same scope, the said options MUST be
discarded.
If asm-length, ssm-length and unicast-length fields are all set to 0,
the DHCPv6 client MUST behave as if OPTION_V6_PREFIX64 had not been
received in the response received from the DHCPv6 server.
If the asm-length field is non-null, the IPv6 prefix identified by
ASM_PREFIX64 is used to synthesize IPv4-embedded IPv6 multicast
Boucadair, et al. Expires December 15, 2016 [Page 5]
Internet-Draft IPv4/IPv6 Multicast Prefixes Option June 2016
addresses in the ASM range. This is achieved by concatenating the
ASM_PREFIX64 and the IPv4 multicast address; the Pv4 multicast
address is inserted in the last 32 bits of the IPv4-embedded IPv6
multicast address.
If the ssm-length field is non-null, the IPv6 prefix identified by
SSM_PREFIX64 is used to synthesize IPv4-embedded IPv6 multicast
addresses in the SSM range. This is achieved by concatenating the
SSM_PREFIX64 and the IPv4 multicast address; the Pv4 multicast
address is inserted in the last 32 bits of the IPv4-embedded IPv6
multicast address.
If the unicast-length field is non-null, the IPv6 prefix identified
by U_PREFIX64 is used to synthesize IPv4-embedded IPv6 unicast
addresses as specified in [RFC6052].
6. Security Considerations
The security considerations documented in [RFC3315] and [RFC6052] are
to be considered.
7. Acknowledgements
Particular thanks to C. Jacquenet, S. Venaas, B. Volz, and T.
Taylor for their review.
Many thanks to I. Farrer and T. Lemon for the comments.
8. IANA Considerations
Authors of this document request IANA to assign a new DHCPv6 option
code in the registry maintained in http://www.iana.org/assignments/
dhcpv6-parameters:
Option Name Value
----------------- -----
OPTION_V6_PREFIX64 TBA
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Boucadair, et al. Expires December 15, 2016 [Page 6]
Internet-Draft IPv4/IPv6 Multicast Prefixes Option June 2016
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<http://www.rfc-editor.org/info/rfc4607>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
9.2. Informative References
[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-12 (work in progress), June 2016.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, DOI 10.17487/RFC2365, July 1998,
<http://www.rfc-editor.org/info/rfc2365>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
the IPv4 Address Shortage", RFC 6346,
DOI 10.17487/RFC6346, August 2011,
<http://www.rfc-editor.org/info/rfc6346>.
[RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of
Solution Proposals for Hosts to Learn NAT64 Prefix",
RFC 7051, DOI 10.17487/RFC7051, November 2013,
<http://www.rfc-editor.org/info/rfc7051>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
DOI 10.17487/RFC7346, August 2014,
<http://www.rfc-editor.org/info/rfc7346>.
Boucadair, et al. Expires December 15, 2016 [Page 7]
Internet-Draft IPv4/IPv6 Multicast Prefixes Option June 2016
Authors' Addresses
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Jacni Qin
Cisco
China
Email: jacni@jacni.com
Tina Tsou
Philips Lighting
Email: tina.tsou@philips.com
Xiaohong Deng
The University of New South Wales
Sydney NSW 2052
Australia
Email: dxhbupt@gmail.com
Boucadair, et al. Expires December 15, 2016 [Page 8]