[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 draft-ietf-dhc-problem-statement-of-mredhcpv6

Internet Engineering Task Force                                   G. Ren
Internet-Draft                                                     L. He
Intended status: Standards Track                                  Y. Liu
Expires: September 20, 2018                          Tsinghua University
                                                          March 19, 2018


   Problem Statement of Multi-requirement Extensions for Dynamic Host
                Configuration Protocol for IPv6 (DHCPv6)
            draft-ren-dhc-problem-statement-of-mredhcpv6-00

Abstract

   The manageability, security, privacy protection, and traceability of
   networks can be supported by extending DHCPv6 protocol.  This
   document analyzes the current extension practices and typical DHCP
   server software on extensions, defines a DHCP general model, lists
   the unresolved problem, and provides the possible directions to solve
   the problems.

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 https://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 September 20, 2018.

Copyright Notice

   Copyright (c) 2018 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
   (https://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



Ren, et al.            Expires September 20, 2018               [Page 1]


Internet-Draft       problem statement of mredhcpv6           March 2018


   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Current Extension Practices . . . . . . . . . . . . . . . . .   3
     3.1.  Standardized and Non-standardized DHCPv6 Extension Cases    3
     3.2.  Current DHCPv6 Server Software Cases  . . . . . . . . . .   4
       3.2.1.  Cisco Prime Network Registrar DHCP Server Extension
               APIs  . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.2.  Kea DHCP Hook Mechanisms  . . . . . . . . . . . . . .   5
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  DHCP General Model  . . . . . . . . . . . . . . . . . . .   5
     4.2.  Unresolved Problems . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  DHCP Messages . . . . . . . . . . . . . . . . . . . .   6
       4.2.2.  Options . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.3.  Message Processing Functions  . . . . . . . . . . . .   6
       4.2.4.  Address Generation Mechanisms . . . . . . . . . . . .   7
       4.2.5.  Extension Principles  . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The IP address plays a significant role in the communication of the
   current Internet.  Also, IP address generation is closely related to
   the manageability, security, privacy protection, and traceability of
   the networks.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   [RFC3315] is an important network protocol that can be used to
   dynamically provide IPv6 addresses and other network configuration
   parameters to IPv6 hosts.  Actually, DHCPv6 continues to be extended
   and improved through being added new options and defined new
   protocols or message processing mechanisms.

   Even if DHCPv6 provides more and more comprehensive functionality and
   many DHCPv6 server software have provided extension interfaces to
   allow users to alter and customize the way how they handle and
   respond to DHCPv6 messages, a general insight of how to solve the
   extension problem effectively is lack.  We should figure out where
   and how to conduct extensions in the DHCPv6.  Therefore, a detailed



Ren, et al.            Expires September 20, 2018               [Page 2]


Internet-Draft       problem statement of mredhcpv6           March 2018


   analysis is required to clarify the problems, design principles, and
   extract and unify the design specifications to help better solve the
   extension problems.

   In summary, multiple extensions can be conducted on DHCPv6 to support
   the user's self-defined functionality.  As DHCPv6 is such an
   important and useful protocol related to IPv6 addresses generation,
   it can provide more extended and flexible functionality to meet
   users' requirements.  According to well-designed principles, extended
   interfaces can be defined to support more self-defined multi-
   requirement extensions without sacrificing the stability of DHCPv6.

   Some people would suggest the user modify the open-source DHCP
   servers to solve their own problem.  However, a great amount of time
   will be taken to understand the open source DHCP server code, not to
   say the consuming time debugging the bugs, failures or system crash
   caused by modifying the complicated modules.  Another problem is that
   as the open source software evolves, the source code of the server
   software may change (new functionality or fixing bugs).  Users may
   need to re-write their codes once the new version of open-source
   server software comes out [kea_dhcp_hook_developers_guide] . Hence,
   the multi-requirement extensions for DHCPv6 to solve users' specific
   problems are very necessary and significant.

   This document describes the current extension practices and typical
   DHCP server software on extensions and provides a problem statement
   by defining a DHCP general model, analyzing the unresolved multi-
   requirement extension problems, and providing possible directions for
   new work that could solve these problems.

2.  Terminology

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

   Familiarity with DHCPv6 and its terminology, as defined in [RFC3315],
   is assumed.

3.  Current Extension Practices

3.1.  Standardized and Non-standardized DHCPv6 Extension Cases

   Many documents attempt to extend the DHCPv6.  They can be classified
   into three categories.

   Extended options    Most extensions for DHCPv6 are implemented in
                       this way, e.g., DNS configurations [RFC3646], NIS



Ren, et al.            Expires September 20, 2018               [Page 3]


Internet-Draft       problem statement of mredhcpv6           March 2018


                       configurations [RFC3898], SNTP configurations
                       [RFC4075], information refresh time
                       configurations [RFC4242], remote-id [RFC4649],
                       FQDN configurations [RFC4704], relay agent echo
                       request [RFC4994], network boot [RFC5970], client
                       link-layer address [RFC6939].  New-defined
                       options carry specific parameters in the DHCPv6
                       messages, which helps DHCPv6 clients or servers
                       know the detailed situation with each other.

   Extended messages   Some documents define new protocols to achieve
                       specific purposes, e.g., secure DHCPv6
                       [draft-ietf-dhc-sedhcpv6-21], active leasequery
                       [RFC7653], GAGMS [GAGMS].  These protocols often
                       requires defining new messages and new options.

   Extended entities   Some documents introduce extra entities into the
                       communications of DHCPv6 to achieve specific
                       purpose, e.g., authentication [RFC7037].

3.2.  Current DHCPv6 Server Software Cases

   Many commercial and open source DHCP server software exist, including
   Cisco Prime Network Registrar [CPNR], Microsoft DHCP
   [Microsoft_DHCP], VitalQIP [VitalQIP], Nominum DHCP [Nominum_DHCP],
   ISC DHCP [ISC_DHCP], Kea DHCP [Kea_DHCP], FreeRADIUS DHCP
   [FreeRADIUS_DHCP], WIDE DHCPv6 [WIDE_DHCPv6], etc.  Commercial and
   open source DHCPv6 software often consider the extensions of DHCPv6
   servers because they all cannot always meet the requirements that the
   users want.  In this section, we introduce two typical DHCPv6
   software: Cisco Prime Network Registrar and Kea DHCP, respectively.

3.2.1.  Cisco Prime Network Registrar DHCP Server Extension APIs

   Cisco Prime Network Registrar (CPNR) [CPNR] is an appliance which
   provides integrated Domain Name Server, DHCP, and IP Address
   Management services for IPv4 and IPv6.  At the same time, CPNR DHCP
   server allows user to write extensions and functions to alter and
   customize how it handles and responds to DHCP requests.  A network
   operator usually decides what packets process to modify, how to
   modify, and which extension point to attach the extension.  Then the
   network operator just writes the extension and adds the well-written
   extension to the extension point of the DHCP server.  Finally, the
   network operator reloads the DHCP server and can find that the server
   will do what he/her wants the server to do.






Ren, et al.            Expires September 20, 2018               [Page 4]


Internet-Draft       problem statement of mredhcpv6           March 2018


3.2.2.  Kea DHCP Hook Mechanisms

   Kea DHCP provides hook mechanisms, a defined interface for third-
   party or user-written code, to solve the problem that the DHCP server
   does not quite do what a network operator require.  A network
   operator can use several well-defined framework functions to load and
   initialize a library and write specific callout functions to attach
   to the hook points.  After building and configuring the hooks
   library, the server will do what the network operator require.
   Additionally, Kea DHCP allows users to use logging in the hooks
   library.

4.  Problem Statement

   This section elaborates the problem statement on multi-requirement
   extensions for DHCPv6.  Section 4.1 describes the general model of
   DHCP, while Section 4.2 analyzes the unresolved problems and
   requirements, suggesting possible future work.

4.1.  DHCP General Model

   Figure 1 summarizes the DHCP general model and its possible
   extensions: DHCP messages, options, message processing functions, and
   address generation mechanisms.

  +-------------------+                            +-------------------+
  |   DHCPv6 client   |                            |   DHCPv6 relay    |
  | +---------------+ | DHCP messages with options | +---------------+ |
  | |   Message     | |<-------------------------> | |   Message     | |
  | |  processing   | |                            | |  processing   | |
  | |  functions    | |                            | |  functions    | |
  | +---------------+ |                            | +---------------+ |
  +-------------------+                            +-------------------+
                                                           ^
                                                           |
                                DHCP messages with options |
                                                           |
                                                           V
                                                   +-------------------+
                                                   |   DHCPv6 server   |
      +------------+                               | +---------------+ |
      |  Address   |                               | |   Message     | |
      | generation |<------------------------------+-|  processing   | |
      | mechanisms |                               | |  functions    | |
      +------------+                               | +---------------+ |
                                                   +-------------------+

         Figure 1: DHCP general model and its possible extensions.



Ren, et al.            Expires September 20, 2018               [Page 5]


Internet-Draft       problem statement of mredhcpv6           March 2018


4.2.  Unresolved Problems

   Currently, DHCPv6 protocol solves the problem that basic options are
   transmitted in plaintext.  However, there are still many problems
   left to be resolved.  Section 4.2.1, Section 4.2.2, Section 4.2.3,
   and Section 4.2.4 discuss these problems.

4.2.1.  DHCP Messages

   People are always concerned about the security and privacy issues of
   DHCP protocol.  [RFC7819] and [RFC7824] consider the privacy issues
   associated with the use of DHCPv4 and DHCPv6 by the Internet users,
   respectively.  The current DHCP protocol does not resolve the problem
   that the options are transmitted in ciphertext.  That is to say, any
   other nodes can see the options transmitted in the DHCPv6 messages
   between a DHCPv6 client and servers.  Secure DHCPv6
   [draft-ietf-dhc-sedhcpv6-21] considers using public cryptography to
   provide a deployable security mechanism, which can transmit basic
   options in DHCP messages exchanged between clients and servers.
   However, this draft is currently dead in IESG.  In fact, new messages
   can be designed and added to DHCPv6 protocol, and DHCP messages can
   be exchanged in either plaintext or ciphertext.

4.2.2.  Options

   In other cases, network operators may require DHCP messages to
   transmit some self-defined options between clients and servers.
   However, no such mechanisms in the current DHCP protocol support this
   requirement.  DHCP clients do not allow users to transmit options not
   defined in standards, and not all DHCP server software support
   transmitting non-standardized options, either.  For example, [NIDTGA]
   modifies the DHCPv6 message exchanges by adding some new options with
   cryptographic options.  However, current DHCP standards do not
   provide related and flexible interfaces to meet such requirements.
   In fact, not only DHCP server software can provide interfaces for
   users to alter the way that they handle and respond to DHCP messages
   to meet their requirements, but DHCP client software can also provide
   such interfaces.

4.2.3.  Message Processing Functions

   Although current commercial or open-source DHCP server software
   provide comprehensive functionality, they still cannot meet all
   customers' requirements of processing DHCP requests.  Therefore,
   improved commercial or open-source DHCP server software will provide
   interfaces that customers can use to write their specific extensions
   to affect the way how DHCP servers handle and respond to DHCP
   requests.  For example, not all networks prefer to use DHCPv6 servers



Ren, et al.            Expires September 20, 2018               [Page 6]


Internet-Draft       problem statement of mredhcpv6           March 2018


   to assign the privacy-preserving random-form addresses generated by
   some fixed address generation mechanism to DHCPv6 clients.  Several
   address generation mechanisms for SLAAC [RFC4862] (e.g., IEEE 64-bit
   EUI-64 [RFC2464], Constant, semantically opaque [Microsoft],
   Temporary [RFC4941], and Stable, semantically opaque [RFC7217])
   proposed for different requirements can be also utilized in DHCPv6
   protocol.  The many types of IPv6 address generation mechanisms
   available have brought about flexibility and diversity.  Thus,
   network operators may alter their DHCPv6 servers through the given
   extensions to use their own preferred address generation mechanisms
   to assign addresses to DHCPv6 clients.  However, not all DHCP
   software consider this extension.

4.2.4.  Address Generation Mechanisms

   Different networks may prefer different address generation
   mechanisms.  However, current DHCPv6 protocol only considers
   generating random IPv6 addresses.  Corresponding interfaces should be
   open and defined to allow other address generation mechanisms to be
   configured.

4.2.5.  Extension Principles

   The principles used to conduct multi-requirement extensions for
   DHCPv6 are summarized as follows:

      1) Do not change the current DHCP general model.

      2) Use simpler interfaces to define and support more extensions.

5.  Security Considerations

   Security issues related with DHCPv6 are described in Section 23 of
   [RFC3315].

   Secure DHCPv6 [draft-ietf-dhc-sedhcpv6-21] attempts to provide a
   deployable security mechanism for end-to-end communication between
   DHCP clients and servers.

6.  IANA Considerations

   This document does not include an IANA request.

7.  Acknowledgements

   The authors would like to thank Bernie Volz, Tomek Mrugalski, Sheng
   Jiang, and Jinmei Tatuya for their comments and suggestions that




Ren, et al.            Expires September 20, 2018               [Page 7]


Internet-Draft       problem statement of mredhcpv6           March 2018


   improved the [draft-ren-dhc-mredhcpv6].  Some ideas and thoughts of
   [draft-ren-dhc-mredhcpv6] are contained in this document.

8.  References

8.1.  Normative References

   [CPNR]     Cisco, "Cisco Prime Network Registrar", 2018,
              <https://www.cisco.com/c/en/us/products/cloud-systems-
              management/prime-network-registrar/index.html>.

   [draft-ietf-dhc-sedhcpv6-21]
              Li, L., Jiang, S., Cui Y., Jinmei T., Lemon, T., and D.
              Zhang, "Secure DHCPv6", August 2017,
              <https://www.ietf.org/archive/id/
              draft-ietf-dhc-sedhcpv6-21.txt>.

   [draft-ren-dhc-mredhcpv6]
              Ren, G., He, L., and Y. Liu, "Multi-requirement Extensions
              for Dynamic Host Configuration Protocol for IPv6
              (DHCPv6)", March 2017.

   [FreeRADIUS_DHCP]
              FreeRADIUS, "FreeRADIUS DHCP", 2017,
              <https://wiki.freeradius.org/features/DHCP>.

   [GAGMS]    Liu, Y., He, L., and G. Ren, "GAGMS: A Requirement-Driven
              General Address Generation and Management System",
              November 2017.

   [ISC_DHCP]
              Internet System Consortium, "ISC DHCP", 2018,
              <http://www.isc.org/downloads/dhcp/>.

   [Kea_DHCP]
              Internet System Consortium, "Kea DHCP", 2018,
              <https://www.isc.org/kea/>.

   [kea_dhcp_hook_developers_guide]
              Internet Systems Consortium, "Hook Developer's Guide",
              2018, <https://jenkins.isc.org/job/Kea_doc/doxygen/df/d46/
              hooksdgDevelopersGuide.html>.

   [Microsoft]
              Microsoft, "IPv6 interface identifiers", 2013, <https://ww
              w.microsoft.com/resources/documentation/windows/xp/all/
              proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true>.




Ren, et al.            Expires September 20, 2018               [Page 8]


Internet-Draft       problem statement of mredhcpv6           March 2018


   [Microsoft_DHCP]
              Microsoft, "Microsoft DHCP", 2008,
              <https://technet.microsoft.com/en-us/library/
              cc896553(v=ws.10).aspx>.

   [NIDTGA]   Liu, Y., Ren, G., Wu J., Zhang s., He, L., and Y. Jia,
              "Building an IPv6 address generation and traceback system
              with NIDTGA in Address Driven Network", 2015,
              <https://link.springer.com/article/10.1007/
              s11432-015-5461-0>.

   [Nominum_DHCP]
              Nominum, "Nominum DHCP", 2012,
              <https://www.nominum.com/press_item/nominum-releases-new-
              version-of-carrier-grade-dhcp-software-for-telecom-
              providers/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
              <https://www.rfc-editor.org/info/rfc2464>.

   [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, <https://www.rfc-editor.org/info/rfc3315>.

   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
              Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              DOI 10.17487/RFC3646, December 2003,
              <https://www.rfc-editor.org/info/rfc3646>.

   [RFC3898]  Kalusivalingam, V., "Network Information Service (NIS)
              Configuration Options for Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6)", RFC 3898,
              DOI 10.17487/RFC3898, October 2004,
              <https://www.rfc-editor.org/info/rfc3898>.

   [RFC4075]  Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
              Configuration Option for DHCPv6", RFC 4075,
              DOI 10.17487/RFC4075, May 2005,
              <https://www.rfc-editor.org/info/rfc4075>.





Ren, et al.            Expires September 20, 2018               [Page 9]


Internet-Draft       problem statement of mredhcpv6           March 2018


   [RFC4242]  Venaas, S., Chown, T., and B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November
              2005, <https://www.rfc-editor.org/info/rfc4242>.

   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
              DOI 10.17487/RFC4649, August 2006,
              <https://www.rfc-editor.org/info/rfc4649>.

   [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
              Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
              <https://www.rfc-editor.org/info/rfc4704>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <https://www.rfc-editor.org/info/rfc4941>.

   [RFC4994]  Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski,
              "DHCPv6 Relay Agent Echo Request Option", RFC 4994,
              DOI 10.17487/RFC4994, September 2007,
              <https://www.rfc-editor.org/info/rfc4994>.

   [RFC5970]  Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6
              Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970,
              September 2010, <https://www.rfc-editor.org/info/rfc5970>.

   [RFC6939]  Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
              Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
              May 2013, <https://www.rfc-editor.org/info/rfc6939>.

   [RFC7037]  Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6
              Relay Agent", RFC 7037, DOI 10.17487/RFC7037, October
              2013, <https://www.rfc-editor.org/info/rfc7037>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.




Ren, et al.            Expires September 20, 2018              [Page 10]


Internet-Draft       problem statement of mredhcpv6           March 2018


   [RFC7653]  Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
              Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
              October 2015, <https://www.rfc-editor.org/info/rfc7653>.

   [RFC7819]  Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
              Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819,
              April 2016, <https://www.rfc-editor.org/info/rfc7819>.

   [RFC7824]  Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
              Considerations for DHCPv6", RFC 7824,
              DOI 10.17487/RFC7824, May 2016,
              <https://www.rfc-editor.org/info/rfc7824>.

   [VitalQIP]
              Nokia, "Nokia VitalQIP", 2017,
              <https://networks.nokia.com/products/
              vitalqip-ip-address-management>.

   [WIDE_DHCPv6]
              KAME project, "WIDE DHCPv6", 2008,
              <http://ipv6int.net/software/wide_dhcpv6.html>.

8.2.  Informative References

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC7749]  Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
              RFC 7749, DOI 10.17487/RFC7749, February 2016,
              <https://www.rfc-editor.org/info/rfc7749>.

Authors' Addresses

   Gang Ren
   Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-010 6260 3227
   Email: rengang@cernet.edu.cn




Ren, et al.            Expires September 20, 2018              [Page 11]


Internet-Draft       problem statement of mredhcpv6           March 2018


   Lin He
   Tsinghua University
   Beijing  100084
   P.R.China

   Email: he-l14@mails.tsinghua.edu.cn


   Ying Liu
   Tsinghua University
   Beijing  100084
   P.R.China

   Email: liuying@cernet.edu.cn





































Ren, et al.            Expires September 20, 2018              [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/