[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Dynamic Host Configuration WG                               T. Mrugalski
Internet-Draft                                                       ISC
Intended status: Standards Track                                   P. Wu
Expires: March 30, 2013                              Tsinghua University
                                                      September 26, 2012


Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for DHCPv4
                           over IPv6 Endpoint
           draft-mrugalski-softwire-dhcpv4-over-v6-option-01

Abstract

   [I-D.ietf-dhc-dhcpv4-over-ipv6] defines a way for communication
   between legacy DHCPv4 clients with DHCPv4 servers over IPv6-only
   transport.  It requires deployment of Client Relay Agent (CRA) that
   transmits messages to IPv6-Transport Server (TSV) or IPv6-Transport
   Relay Agent (TRA).  Deployed CRA must know an address of TSV or TRA
   to forward incoming client's messages.  This document defines a
   DHCPv6 option that may be used to provision TSV or TRA location to
   CRAs.

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 March 30, 2013.

Copyright Notice

   Copyright (c) 2012 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



Mrugalski & Wu           Expires March 30, 2013                 [Page 1]


Internet-Draft       DHCPv4 over IPv6 DHCPv6 Option       September 2012


   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.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The DHCPv4-Over-IPv6 Endpoint DHCPv6 Option . . . . . . . . . . 3
   4.  DHCPv6 Server Behavior  . . . . . . . . . . . . . . . . . . . . 4
   5.  DHCPv6 Client Behavior  . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7






























Mrugalski & Wu           Expires March 30, 2013                 [Page 2]


Internet-Draft       DHCPv4 over IPv6 DHCPv6 Option       September 2012


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

   [I-D.ietf-dhc-dhcpv4-over-ipv6] defines a way for communication
   between legacy DHCPv4 clients with DHCPv4 servers (defined in
   [RFC2131]) over IPv6-only transport.  It requires deployment of
   Client Relay Agent (CRA) that transmits messages to IPv6-Transport
   Server (TSV) or IPv6-Transport Relay Agent (TRA).  Although there are
   several scenarios envisaged, all of them assume that CRA needs to
   know the recipient address of the DHCPv4-over-IPv6 traffic.  In a
   typical deployment as [I-D.cui-softwire-b4-translated-ds-lite] or
   [I-D.ietf-softwire-public-4over6], CRA functionality will be a part
   of a Lightweight B4 element (Basic Bridging BroadBand element)
   implementation.

   Depending on the scenario discussed, the DHCPv4 over IPv6 transport
   endpoint could be either an IPv6-Transport Server (TSV) or an IPv6-
   Transport Relay Agent (TRA).  Both cases are indistinguishable from
   CRA perspective.  CRA needs to know TSV's or TRA's IPv6 address in
   advance to relay traffic.  Again, the typical envisaged use would be
   the Lightweight 4over6 architecture, where TSV or TRA could be part
   of Lightweight AFTR implementation.

   As CRA uplink is IPv6-only (otherwise there would be no need to
   deploy DHCPv4 over IPv6), the only feasible way to provision
   information to CRA is over DHCPv6.  Therefore this document specifies
   a DHCPv6 option that conveys necessary information.

   To provide the conveyance of the configuration information, a single
   DHCPv6 [RFC3315] option is used, expressing the TRA's or TSV's IPv6
   address to the CRA.


3.  The DHCPv4-Over-IPv6 Endpoint DHCPv6 Option

   The DHCPv4-over-IPv6 option is a DHCPv6 option.  It consists of an
   option-code and option-len fields (as all DHCPv6 options have), and a
   fixed-length dhcpv4-over-ipv6-endpoint-addr field containing an IPv6
   address that refers to the DHCPv4 over IPv6 transport endpoint to
   which the CRA MAY transport DHCPv4 traffic.  This address represents
   TRA or TSV, depending on deployment scenario.




Mrugalski & Wu           Expires March 30, 2013                 [Page 3]


Internet-Draft       DHCPv4 over IPv6 DHCPv6 Option       September 2012


   The DHCPv4-over-IPv6 option SHOULD NOT appear in any other than the
   following DHCPv6 messages: Solicit, Advertise, Request, Renew,
   Rebind, Information-Request and Reply.

   The format of the DHCPv4 over IPv6 option is shown in the following
   figure:

      0                   1                   2                   3
      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_DHCP4_OVER_V6: (TBD)   |          option-len           |
     +-------------------------------+-------------------------------+
     |                                                               |
     |              dhcpv4-over-ipv6-endpoint-addr                   |
     |                                                               |
     +---------------------------------------------------------------+

      OPTION_DHCP4_OVER_V6: (TBD)

                option-len: 16

       dhcpv4-over-ipv6-endpoint-addr: An IPv6 address of the
                                 DHCPv4-over-IPv6 transport endpoint.

                 Figure 1: AFTR-Name DHCPv6 Option Format

   The option is validated by confirming that all of the following
   conditions are met:

   1.  the option-len is exactly 16;

   2.  the dhcpv4-over-ipv6-endpoint-addr contains valid unicast
       address.  In particular any address (::), multicast (ff::/8) or
       IPv4-mapped IPv6 address is invalid and MUST be rejected.


4.  DHCPv6 Server Behavior

   A DHCPv6 server SHOULD NOT send more than one DHCPv4-over-IPv6
   option.  It SHOULD NOT permit the configuration of multiple addresses
   within one DHCPv4-over-IPv6 option.  Both of these conditions are
   handled as errors by the client, so an operator using software that
   does not perform these validations should be careful not to configure
   multiple addresses.

   RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and
   server negotiate configuration values using the Option Request Option
   (OPTION_ORO).  As a convenience to the reader, we mention here that a



Mrugalski & Wu           Expires March 30, 2013                 [Page 4]


Internet-Draft       DHCPv4 over IPv6 DHCPv6 Option       September 2012


   server will not reply with a DHCPv4-over-IPv6 option if the client
   has not explicitly enumerated it on its Option Request Option.  In
   other words, server SHOULD send this option only if client explicitly
   requested it in ORO.


5.  DHCPv6 Client Behavior

   A client that supports the DHCPv4 over IPv6 functionality of and
   conforms to this specification MUST include OPTION_DHCP4_OVER_V6 on
   its OPTION_ORO.

   If the client receives the DHCPv4-over-IPv6 option, it MUST verify
   the option contents as described in Section 3.

   If the CRA entity receives more than one DHCPv4-over-IPv6 option, it
   MUST use only one instance of that option.

   If the DHCPv4-over-IPv6 option contains more than one address, the
   CRA entity system MUST ignore the option.  It SHOULD warn its
   operator about such condition.

   Note that a CRA system may have multiple network interfaces, and
   these interfaces may be configured differently; some may be connected
   to networks that call for DHCPv4-over-IPv6, and some may be connected
   to networks that are using normal dual stack or other means.  The CRA
   entity should approach this specification on an interface-by-
   interface basis.  For example, if the CRA entity is attached to
   multiple networks that provide the DHCPv4-over-IPv6 option, then the
   CRA entity MUST configure a DHCPv4 over IPv6 transport for each
   interface separately as each transport provides IPv4 connectivity for
   each distinct interface.


6.  Security Considerations

   This document does not present any new security issues, but as with
   all DHCPv6-derived configuration state, it is completely possible
   that the configuration is being delivered by a third party (Man In
   The Middle).  As such, there is no basis to trust that the access the
   DHCPv4-over-IPv6 connection provides can be trusted.  It should be
   protected by available security mechanisms such as IP firewalls.

   It should be noted that DHCPv4 over IPv6 traffic may bypass existing
   firewalls that are typically configured to drop incoming outside
   DHCPv4 over IPv4 and DHCPv6 over IPv6 traffic.

   RFC 3315 [RFC3315] discusses DHCPv6-related security issues.



Mrugalski & Wu           Expires March 30, 2013                 [Page 5]


Internet-Draft       DHCPv4 over IPv6 DHCPv6 Option       September 2012


   [I-D.ietf-dhc-dhcpv4-over-ipv6] discusses DHCPv4-over-IPv6 related
   security issues.


7.  IANA Considerations

   IANA is kindly requested to allocate DHCPv6 option code TBD to the
   OPTION_DHCP4_OVER_V6.  The value should be added to the DHCPv6 option
   code space defined in Section 24.3 of [RFC3315].


8.  Acknowledgements

   Authors would like to thank nobody so far, as we have not received
   any comments yet.

   This work has been partially supported by the Polish Ministry of
   Science and Higher Education under the European Regional Development
   Fund, Grant No.  POIG.01.01.02-00-045/09-00 (Future Internet
   Engineering Project).


9.  References

9.1.  Normative References

   [I-D.ietf-dhc-dhcpv4-over-ipv6]
              Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
              Transport", draft-ietf-dhc-dhcpv4-over-ipv6-05 (work in
              progress), September 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

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

9.2.  Informative References

   [I-D.cui-softwire-b4-translated-ds-lite]
              Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the DS-Lite
              Architecture", draft-cui-softwire-b4-translated-ds-lite-08
              (work in progress), September 2012.



Mrugalski & Wu           Expires March 30, 2013                 [Page 6]


Internet-Draft       DHCPv4 over IPv6 DHCPv6 Option       September 2012


   [I-D.ietf-softwire-public-4over6]
              Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
              IPv4 over IPv6 Access Network",
              draft-ietf-softwire-public-4over6-03 (work in progress),
              August 2012.


Authors' Addresses

   Tomasz Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063
   USA

   Phone: +1 650 423 1345
   Email: tomasz.mrugalski@gmail.com


   Peng Wu
   Tsinghua University
   Beijing  100084
   P.R.China

   Email: pengwu.thu@gmail.com


























Mrugalski & Wu           Expires March 30, 2013                 [Page 7]


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