Network Working Group                                           O. Troan
Internet-Draft                                                     Cisco
Intended status: Informational                               M. Blanchet
Expires: April 12, October 28, 2012                                       Viagenie
                                                                   X. Xu
                                                                  D. Guo
                                                     Huawei Technologies
                                                             W. Townsley
                                                        October 10, 2011
                                                          April 28, 2012

                         DHCPv6 through Tunnels


   The host configuration protocol DHCPv6 [RFC3315] relies on link-local
   addresses as source addresses and multicast to function. addresses for destination
   addresses.  However, most of the existing
   6over4 some tunnel link types links (e.g., 6rd [RFC5969] ) don't support do not
   have IPv6 link-local addresses and even do not support IPv6 multicast
   addresses.  Taking 6rd as an example, this document specifies how
   DHCPv6 can be is used across such tunnel links . links.

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

   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 April 12, October 28, 2012.

Copyright Notice

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

   Various tunnel techniques are used to deploy IPv6 over IPv4, such as
   6rd.  The source tunnel end-point typically generates its IPv6 global
   address and for some tunnel techniques such as 6rd, generates a
   prefix for the downstream network.  By some means, the source tunnel
   end-point always knows the IPv6 address of the other tunnel end-

   The source tunnel end-point often need more configuration data for
   itself and its downstream network, such as DNS, SIP, NTP IPv6 server
   addresses or else.  Therefore, the source tunnel end-point needs to
   send DHCPv6 requests over its IPv6 upstream link, the tunnel link.

   As specified in the DHCPv6 specification [RFC3315], "...The client
   MUST use a link-local address assigned to the interface for which it
   is requesting configuration information as the source address in the
   header of the IP datagram." and "...Unless otherwise specified in
   this document, or in a document that describes how IPv6 is carried
   over a specific type of link (for link types that do not support
   multicast), a client sends DHCP messages to the

   However, link-local addresses and even multicast addresses are not
   supported over most of the existing 6over4 some tunnel link types. 6rd links such as
   described in 6rd [RFC5969] is a real example. .

   Taking 6rd as an example, this document describes how DHCPv6 service
   can be provided across such tunnel links .

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Using DHCPv6 over 6rd links Tunnel Links

   There are two problems to be solved with regards to providing DHCPv6
   service over a 6rd link:
   o  A DHCPv6 client uses an IPv6 link-local address as the source
      address when requesting configuration information [RFC3315].
      Link-local addressing is not supported on an 6rd link.
   o  A DHCPv6 client sends a request to the
      All_DHCP_Relay_Agent_and_Servers multicast address. 6rd as
      specified in [RFC5969] does not support IPv6 multicast.

   The first problem can be solved by changing the DHCPv6 protocol to
   allow for

   This document describes a global address possible solution to be used as the source address in
   requests.  Another solution that does not above two problems
   which doesn't require any change to the DHCPv6 protocol changes, [RFC3315] .
   The basic idea of this solution is to send DHCPv6 requests via a
   local DHCPv6 relay on the 6rd CE.

   The 6rd CE MUST support a local DHCPv6 client and relay.  The DHCPv6
   client running on the 6rd CE's virtual tunnel interface MUST send
   DHCPv6 messages through a local DHCPv6 relay that encapsulates the
   client message and forwards it to a DHCPv6 server or relay using one
   of the 6rd CE's global unicast addresses as the source address.

   The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast
   address as the destination address, section 20 of [RFC3315].  If the
   6rd link supports multicast [I-D.ietf-mboned-auto-multicast] the 6rd
   CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the
   destination address of Relay-forward messages.

   The 6rd BRs in the 6rd domain must MUST be configured as DHCPv6 relays or
   servers on their 6rd virtual interfaces.

   The 6rd CE SHOULD behave according to
   [I-D.ietf-v6ops-ipv6-cpe-router].  In particular it operates a DHCPv6
   client on the WAN side (6rd virtual) interface and as a DHCPv6 server
   on the LAN-side interface(s).

4.  IANA Considerations

   This specification does not require any IANA actions.

5.  Security Considerations

   There are no new security considerations pertaining to this document.

6.  Acknowledgements

   The authors would like to thank Ted Lemon, Fred Templin Templin, Brian E
   Carpenter and other people for their valuable comments.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, 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.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",
              RFC 5969, August 2010.

7.2.  Informative References

              Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L.,
              Pusateri, T., and T. Morin,
              Bumgardner, G., "Automatic IP Multicast Tunneling", draft-ietf-mboned-auto-multicast-11
              draft-ietf-mboned-auto-multicast-13 (work in progress), July 2011.
              April 2012.

              Singh, H., Beebee, W., Donley, C., Stark, B., and O.
              Troan, "Basic Requirements for IPv6 Customer Edge
              Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in
              progress), December 2010.

Authors' Addresses

   Ole Troan

   Marc Blanchet
   2875 boul. Laurier, suite D2-630


   Xiaohu Xu
   Huawei Technologies
   No.3 Xinxi Rd., Shang-Di Information Industry Base
   Beijing,   100085
   P.R. China

   Phone: +86 10 82882573

   Dayong Guo
   Huawei Technologies
   No.3 Xinxi Rd., Shang-Di Information Industry Base
   Beijing, Hai-Dian District  100085
   P.R. China

   Phone: +86-10-82882578

   Mark Townsley