Internet DRAFT - draft-fsc-dhc-dhcp4o6-saddr-opt
draft-fsc-dhc-dhcp4o6-saddr-opt
DHC WG I. Farrer
Internet-Draft Deutsche Telekom AG
Intended status: Standards Track Q. Sun
Expires: August 16, 2014 Y. Cui
Tsinghua University
February 12, 2014
DHCPv4 over DHCPv6 Source Address Option
draft-fsc-dhc-dhcp4o6-saddr-opt-00
Abstract
DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes one
possible mechanism for dynamically configuring IPv4 over an IPv6 only
network. For DHCPv4 over DHCPv6 to function with some softwire
mechanisms, the operator must obtain information about the DHCP 4o6
client's allocated IPv4 address and PSID, as well as the /128 IPv6
prefix that the client will use as the source of IPv4-in-IPv6 tunnel.
This memo defines a DHCPv6 option to convey this IPv6 prefix between
the DHCP 4o6 client and server. It is designed to work in
conjunction with the DHCPv4 IPv4 address allocation process message
flow.
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].
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 16, 2014.
Farrer, et al. Expires August 16, 2014 [Page 1]
Internet-Draft DHCP 4o6 SADDR option February 2014
Copyright Notice
Copyright (c) 2014 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
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
2. Applicabiliity . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes a
mechanism for dynamically configuring IPv4 over an IPv6 only network
by transporting the complete set of DHCPv4 messages within a specific
pair of DHCPv6 messages. The IPv4 configuration provisioned to the
DHCP 4o6 clients is then generally used for configuring IPv4 over
IPv6 services. IPv4 addresses can be dynamically leased to DHCP 4o6
clients in the same manner as IPv4 addresses are leased to DHCPv4
clients in IPv4 networks. The main advantages to this approach is a
greater efficiency in the use of limited IPv4 address resources over
IPv6 networks.
Currently defined IPv4 over IPv6 transition technologies are, by
design, quite prescriptive in the location of the tunnel endpoint
within the home network. The tunnel endpoint must usually be
configured on either the home gateway device, or sourced from a very
specific IPv6 tunnel prefix allocated to the home network (and in
some cases, both). This is necessary to enable the end-to-end
Farrer, et al. Expires August 16, 2014 [Page 2]
Internet-Draft DHCP 4o6 SADDR option February 2014
provisioning chain between the IPv4-over-IPv6 client in the home
network, the border router (the egress point from the IPv4 over IPv6
domain to the IPv4-only domain) and the provisioning systems
responsible for configuring the functional elements.
The dynamic leasing of IPv4 addresses to clients alters this end-to-
end provisioning chain. It can no longer be assumed that a Softwire
Initiator sourcing from a specific IPv6 prefix have to use a certain
IPv6 address as the source for encapsulating its IPv4 packets.
Therefore, a mechanism is necessary to inform the service provider of
the binding between the allocated IPv4 address (learnt through
DHCPv4) and the IPv6 address that the IPv4 over IPv6 client will use
for accessing IPv4-over-IPv6 services. The service provider can then
use this binding information to provision other functional elements
it their network such as the border router accordingly.
A second benefit of such a mechanism is that it allows much more
flexibility in the location of the IPv4 over IPv6 tunnel endpoint as
this will be dynamically signalled back to the service provider. The
DHCP 4o6 client and tunnel client could be run on end devices
attached to any valid IPv6 prefix allocated to an end-user, located
anywhere within an arbitrary home network topology.
As The DHCP 4o6 server manages the leasing of IPv4 addresses to the
DHCP 4o6 clients, which runs on the Softwire Initiators, it holds the
most accurate IPv4 lease information available across the IPv6
network between the server and the client. It follows that the DHCP
4o6 server should also hold information about the /128 IPv6 prefixes
that active clients are using, so that the server contains a single,
comprehensive and up to date dynamic IPv4/IPv6 binding table.
This memo describes a DHCPv6 option so that the server can indicate
to the client a preferred IPv6 prefix to use (if necessary) and for
the client to signal back the /128 IPv6 prefix that they will bind
the allocated IPv4 configuration to. The DHCP 4o6 server then stores
this information alongside the IPv4 lease information.
Current mechanisms suitable for extending to incorporate DHCPv4 over
DHCPv6 with dynamic IPv4 address leasing include
[I-D.ietf-softwire-map] and [I-D.ietf-softwire-lw4over6]. For these
mechanisms to function, the operator needs the information about the
DHCP 4o6 client's allocated IPv4 address, PSID and also the /128 IPv6
prefix that the client will use to source the IPv4-in-IPv6 tunnel
endpoint.
Farrer, et al. Expires August 16, 2014 [Page 3]
Internet-Draft DHCP 4o6 SADDR option February 2014
2. Applicabiliity
Although DHCPv4 over DHCPv6 is used as the configuration protocol
throughout this document, the DHCPv6 option and provisioning process
which is described here may also be used with other DHCP based IPv4
over IPv6 configuration mechanisms, such as DHCPv4 over IPv6
[I-D.ietf-dhc-dhcpv4-over-ipv6].
3. Solution Overview
The DHCPv6 option (OPTION_DHCPV4OV6_SADDR) described by this memo is
intended to be used alongside the normal DHCPv4 IPv4 address
allocation message flow as described in [RFC2131], in the context of
DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] . It is a two-
way communication process, allowing the service provider to
(optionally) indicate to the client a preferred prefix alongside the
DHCPOFFER message, which can be used for binding the received IPv4
configuration and sourcing tunnel traffic. When the client has
selected the IPv6 prefix to bind the IPv4 configuration to, it passes
this back to the DHCP 4o6 server along with the DHCPREQUEST message.
This may be necessary if there are multiple IPv6 prefixes in use in
the customer network, or if the specific IPv4 over IPv6 transition
mechanism requires the use of a particular prefix for any reason.
The following diagram shows the client/server message flow and how
the different fields of OPTION_DHCPV4OV6_SADDR are used. In each
step, the relevant DHCPv4 message is given above the arrow and the
relevant paramaters used in OPTION_DHCPV4OV6_SADDR's fields below the
arrow.
Farrer, et al. Expires August 16, 2014 [Page 4]
Internet-Draft DHCP 4o6 SADDR option February 2014
DHCP 4o6 DHCP 4o6
Client Server
| DHCPDISCOVER |
Step 1 |-------------------------------------------->|
| OPTION_DHCPV4OV6_SADDR (blank fields) |
| |
| DHCPOFFER |
Step 2 |<--------------------------------------------|
| OPTION_DHCPV4OV6_SADDR (cipv6-prefix-hint |
| with service provider's preferred prefix) |
| |
| DHCPREQUEST |
Step 3 |-------------------------------------------->|
| OPTION_DHCPV4OV6_SADDR (cipv6-bound-prefix |
| with client's bound /128 IPv6 prefix) |
| |
| DHCPACK |
Step 4 |<--------------------------------------------|
| OPTION_DHCPV4OV6_SADDR (cipv6-bound-prefix |
| with client's bound /128 IPv6 prefix) |
| |
IPv6/IPv4 Binding Message Flow
The OPTION_DHCPV4OV6_SADDR (defined below) option is included by the
DHCP 4o6 client within DHCPv4-query messages. The DHCP 4o6 server
MAY reply with this option within DHCPv4-response messages.
The DHCP 4o6 Server and Client MAY implement the
OPTION_DHCPV4OV6_SADDR option. If used, this option MUST be present
within all future DHCPv4 over DHCPv6 transactions.
The option comprises of two prefixes (with associated prefix length
fields):
cipv6-prefix-hint Used by the server to indicate a preferred prefix
that the client should use to bind IPv4
configuration to. If this field contains a
prefix, the client MUST perform a longest prefix
match between cipv6-prefix-hint and all prefixes
configured on the device. The selected prefix
MUST then be used to bind the received IPv4
configuration to. If this field is left blank,
then the client can select any valid IPv6 prefix.
cipv6-bound-prefix Used by the client to inform the DHCP 4o6 Server
of the IPv6 prefix that it has bound the IPv4
Farrer, et al. Expires August 16, 2014 [Page 5]
Internet-Draft DHCP 4o6 SADDR option February 2014
configuration to. This MUST be a /128 prefix
configured on the client.
4. DHCPv4 over DHCPv6 Source Address Option
The format of DHCPv4 over DHCPv6 Source address option is defined as
follows:
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_DHCPV4OV6_SADDR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipv6-hintlen | |
+-+-+-+-+-+-+-+-+ cipv6-prefix-hint .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|cipv6-boundlen | |
+-+-+-+-+-+-+-+-+ cipv6-bound-prefix .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_DHCPV4OV6_SADDR (TBA)
o option-length: 2 + length of cipv6-prefix-hint + length of cipv6
-bound-prefix, specified in bytes.
o cipv6-hintlen: 8-bit field expressing the bit mask length of the
IPv6 prefix specified in cipv6-prefix-hint.
o cipv6-prefix-hint: The IPv6 prefix that the server uses to
indicate the preferred prefix that the client should use to bind
IPv4 configuration to.
o cipv6-boundlen: 8-bit field expressing the bit mask length of the
IPv6 prefix specified in cipv6-bound-prefix. Default: 128.
o cipv6-bound-prefix: The IPv6 prefix that the client is using to
bind the allocated IPv4 configuration to.
5. Security Considerations
TBD
6. IANA Considerations
IANA is requested to allocate the DHCPv6 option code:
OPTION_DHCPV4OV6_SADDR.
Farrer, et al. Expires August 16, 2014 [Page 6]
Internet-Draft DHCP 4o6 SADDR option February 2014
7. Acknowledgements
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-dhc-dhcpv4-over-dhcpv6]
Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
dhcpv4-over-dhcpv6-04 (work in progress), January 2014.
[I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4
over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08
(work in progress), October 2013.
[I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-06 (work
in progress), February 2014.
[I-D.ietf-softwire-map-dhcp]
Mrugalski, T., Troan, O., Dec, W., Bao, C.,
leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options
for configuration of Softwire Address and Port Mapped
Clients", draft-ietf-softwire-map-dhcp-06 (work in
progress), November 2013.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-10
(work in progress), January 2014.
[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.
Farrer, et al. Expires August 16, 2014 [Page 7]
Internet-Draft DHCP 4o6 SADDR option February 2014
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC6148] Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Lease
Query by Relay Agent Remote ID", RFC 6148, February 2011.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011.
Authors' Addresses
Ian Farrer
Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151
Bonn, NRW 53227
Germany
Email: ian.farrer@telekom.de
Qi Sun
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: sunqi@csnet1.cs.tsinghua.edu.cn
Yong Cui
Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn
Farrer, et al. Expires August 16, 2014 [Page 8]
