Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8115.
Authors Mohamed Boucadair , Jacni Qin , Tina Tsou (Ting ZOU) , Xiaohong Deng
Last updated 2017-02-02
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Ian Farrer
Shepherd write-up Show Last changed 2016-11-04
IESG IESG state Became RFC 8115 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Terry Manderson
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
draft-ietf-softwire-multicast-prefix-option-14
Softwire WG                                                 M. Boucadair
Internet-Draft                                                    Orange
Intended status: Standards Track                                  J. Qin
Expires: August 6, 2017                                            Cisco
                                                                 T. Tsou
                                                        Philips Lighting
                                                                 X. Deng
                                       The University of New South Wales
                                                        February 2, 2017

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

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 August 6, 2017.

Copyright Notice

   Copyright (c) 2017 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 August 6, 2017                 [Page 1]
Internet-Draft     IPv4/IPv6 Multicast Prefixes Option     February 2017

   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.  OPTION_V6_PREFIX64 DHCPv6 Option  . . . . . . . . . . . . . .   3
   4.  Configuration Guidelines for the Server . . . . . . . . . . .   5
   5.  DHCPv6 Client Behavior  . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     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 August 6, 2017                 [Page 2]
Internet-Draft     IPv4/IPv6 Multicast Prefixes Option     February 2017

   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_mPrefix64:  a multicast Prefix64 which belongs to the Any-Source
      Multicast (ASM) range.

   SSM_mPrefix64:  a multicast Prefix64 which belongs to the Source-
      Specific Multicast (SSM) [RFC4607] range.

   uPrefix64:  a unicast Prefix64 for building the IPv4-embedded IPv6
      addresses of multicast sources in SSM mode.

3.  OPTION_V6_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_mPrefix64                           :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  ssm-length   |                                               |
     +-+-+-+-+-+-+-+-+                                               :
     :                        SSM_mPrefix64                          :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | unicast-length|                                               |
     +-+-+-+-+-+-+-+-+                                               :
     :                   uPrefix64 (Variable)                        :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: OPTION_V6_PREFIX64: Option Format

   The fields of the option shown in Figure 1 are as follows:

   option-code:  OPTION_V6_PREFIX64 (see Section 8).

Boucadair, et al.        Expires August 6, 2017                 [Page 3]
Internet-Draft     IPv4/IPv6 Multicast Prefixes Option     February 2017

   option-length:  length of the option, in octets.

   asm-length:  the prefix-length for the ASM IPv4-embedded prefix, as
      an 8-bit unsigned integer.  This field represents the number of
      valid leading bits in the prefix.  This field MUST be set to 96.

   ASM_mPrefix64:  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.  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.  This field represents the number of
      valid leading bits in the prefix.  This field MUST be set to 96.

   SSM_mPrefix64:  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.  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.  As specified in
      [RFC6052], the unicast-length MUST be one of 32, 40, 48, 56, 64,
      or 96.  This field represents the number of valid leading bits in
      the prefix.

   uPrefix64:  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.
      uPrefix64 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].

   Multiple instances of OPTION_V6_PREFIX64 may be returned to a DHCPv6
   client.

   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 to support the
   Well-Known DNS Name heuristic discovery-based method for unicast-only
   environments (Section 6 of [RFC7051]).

Boucadair, et al.        Expires August 6, 2017                 [Page 4]
Internet-Draft     IPv4/IPv6 Multicast Prefixes Option     February 2017

4.  Configuration Guidelines for the Server

   This section is not normative but specifies a set of configuration
   guidelines.

   DHCP servers supporting OPTION_V6_PREFIX64 must be configured with
   ASM_mPrefix64 or SSM_mPrefix64, and may be configured with both.
   uPrefix64 must also be configured when SSM_mPrefix64 is provided.
   uPrefix64 may be configured when ASM_mPrefix64 is provided.  Note
   that uPrefix64 is not mandatory for the ASM case if, for example, a
   local address mapping algorithm is supported or the Well-Known Prefix
   (64:ff9b::/96) is used.

   When a multicast Prefix64 (ASM_mPrefix64 or SSM_mPrefix64) is
   configured, the length of the prefix must be /96.

   Both ASM_mPrefix64 and SSM_mPrefix64 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_mPrefix64 and SSM_mPrefix64 prefixes must be
   configured.  For SSM deployments, both SSM_mPrefix64 and uPrefix64
   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 code 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
      [RFC7346], 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.

Boucadair, et al.        Expires August 6, 2017                 [Page 5]
Internet-Draft     IPv4/IPv6 Multicast Prefixes Option     February 2017

   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_mPrefix64 is used to synthesize IPv4-embedded IPv6 multicast
   addresses in the ASM range.  This is achieved by concatenating the
   ASM_mPrefix64 and the IPv4 multicast address; the IPv4 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_mPrefix64 is used to synthesize IPv4-embedded IPv6 multicast
   addresses in the SSM range.  This is achieved by concatenating the
   SSM_mPrefix64 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 uPrefix64 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.  Acknowledgments

   Thanks to C.  Jacquenet, S.  Venaas, B.  Volz, T.  Taylor, R.  Weber,
   R.  Even, J.  Sheng, T.  Mrugalski, and T.  Chown 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

Boucadair, et al.        Expires August 6, 2017                 [Page 6]
Internet-Draft     IPv4/IPv6 Multicast Prefixes Option     February 2017

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

   [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]
              Boucadair, M., Qin, J., 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-17 (work in progress), February 2017.

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

Boucadair, et al.        Expires August 6, 2017                 [Page 7]
Internet-Draft     IPv4/IPv6 Multicast Prefixes Option     February 2017

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

Authors' Addresses

   Mohamed Boucadair
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

   Jacni Qin
   Cisco
   P.R. China

   Email: jacni@jacni.com

   Tina Tsou
   Philips Lighting
   United States of America

   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 August 6, 2017                 [Page 8]