DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes
draft-ietf-softwire-multicast-prefix-option-04

Abstract

This document defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast transition solutions, aiming to convey the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.

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 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.

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 to embed IPv4 addresses, for both multicast group, and multicast source addresses.

This document defines a DHCPv6 option [RFC3315] to convey the IPv6 prefixes to be used for constructing these IPv4-embedded IPv6 addresses.

This option can be in particular 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

3. PREFIX64 DHCPv6 Option

 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_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_PREFIX64 (see Section 8).
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 such case any additional padding bits must be zeroed. The conveyed multicast IPv6 prefix MUST belong to the ASM range. This prefix is likely to be a /96.
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. This prefix is likely to be a /96.
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 such case any additional padding bits must be zeroed. The address mapping MUST follow the guidelines documented in [RFC6052].

4. Configuration Guidelines (Server Side)

DHCP servers supporting OPTION_PREFIX64 should be configured with U_PREFIX64 and at least one ASM_PREFIX64 or one SSM_PREFIX64.

When ASM_PREFIX64 and SSM_PREFIX64 are configured, the length of these prefixes must be /96.

Both ASM_PREFIX64 and SSM_PREFIX64 may be configured and therefore be returned to a requesting DHCP client; it is deployment-specific. 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 should be configured.

5. DHCPv6 Client Behaviour

To retrieve the IPv6 prefixes that will be used to synthesize unicast and multicast IPv4-embedded IPv6 addresses, the DHCPv6 client MUST include OPTION_PREFIX64 in its OPTION_ORO. If the DHCPv6 client receives more than one OPTION_PREFIX64 option from the DHCPv6 server:

If all the enclosed IPv4-embedded IPv6 multicast prefixes have the same scope, the first instance of the option MUST be used.
If each enclosed IPv4-embedded IPv6 multicast prefix has a distinct scope, the client MUST select the appropriate IPv4-embedded IPv6 multicast prefix having a scope matching the IPv4 multicast address used to synthesize an IPv4-embedded IPv6 multicast address.

If asm-length, ssm-length and unicast-length fields are all set to 0, the DHCPv6 client MUST behave as if OPTION_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 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 field 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.

8. IANA Considerations

Authors of this document requests IANA to assign a new DHCPv6 option:

                                Option Name Value
                          ----------------- -----
                            OPTION_PREFIX64 TBA

9. References

9.1. Normative References

[RFC3315]	Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6052]	Bao, C., Huitema, C., Bagnulo, M., Boucadair, M. and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC4607]	Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

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", Internet-Draft draft-ietf-softwire-dslite-multicast-04, October 2012.
[RFC6346]	Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6333]	Durand, A., Droms, R., Woodyatt, J. and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.

Authors' Addresses

Mohamed Boucadair France Telecom Rennes, 35000 France EMail: mohamed.boucadair@orange.com

Jacni Qin Cisco China EMail: jacni@jacni.com

Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, USA Phone: +1 408 330 4424 EMail: tina.tsou.zouting@huawei.com

Xiaohong Deng APNIC Australia EMail: dxhbupt@gmail.com