Internet DRAFT - draft-fsc-softwire-dhcp4o6-saddr-opt
draft-fsc-softwire-dhcp4o6-saddr-opt
Softwire WG I. Farrer
Internet-Draft Deutsche Telekom AG
Updates: RFC7568 (if approved) Q. Sun
Intended status: Standards Track Y. Cui
Expires: August 5, 2017 L. Sun
Tsinghua University
February 1, 2017
DHCPv4 over DHCPv6 Source Address Option
draft-fsc-softwire-dhcp4o6-saddr-opt-07
Abstract
DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically
configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6
to function with some IPv4-over-IPv6 softwire mechanisms and
deployment scenarios, the operator must learn the /128 IPv6 address
that the client will use as the source of IPv4-in-IPv6 tunnel. This
address, in conjunction with the IPv4 address and the Port Set ID
allocated to the DHCP 4o6 client are used to create a binding table
entry in the softwire tunnel concentrator. This memo defines two
DHCPv6 options used to communicate the source tunnel IPv6 address
between the DHCP 4o6 client and server. It also describes a method
for configuring the client with the IPv6 address of the border router
so that the softwire can be established. It is designed to work in
conjunction with the IPv4 address allocation process.
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 5, 2017.
Farrer, et al. Expires August 5, 2017 [Page 1]
Internet-Draft DHCP 4o6 SADDR option February 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
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. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Provisioning the BR Address . . . . . . . . . . . . . . . 4
5. IPv6/IPv4 Binding Message Flow . . . . . . . . . . . . . . . 4
6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. DHCPv4 over DHCPv6 Source Address Hint Option . . . . . . 6
6.1.1. Client Option Validation Behavior . . . . . . . . . . 6
6.2. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Deterministic IPv4-over-IPv6 transition technologies require that
elements are pre-configured with binding rules for routing traffic to
clients. This places a constraint on the location of the client's
tunnel endpoint: The tunnel endpoint has to be a pre-determined
prefix which is usually be configured on the home gateway device.
[RFC7597] describes a DHCPv6 based mechanism for provisioning such
deterministic softwires.
A dynamic provisioning model, such as using DHCPv4 over DHCPv6
[RFC7341] allows much more flexibility in the location of the IPv4-
over-IPv6 tunnel endpoint, as the IPv6 address is dynamically
Farrer, et al. Expires August 5, 2017 [Page 2]
Internet-Draft DHCP 4o6 SADDR option February 2017
signalled back to the service provider so that the corresponding
tunnel configuration in the border router (BR) can be created. The
DHCP 4o6 client and tunnel client could be run on end devices
attached to any routable IPv6 prefix allocated to an end-user,
located anywhere within an arbitrary home network topology. Dynamic
allocation also helps to optimize IPv4 resource usage as only clients
which are currently active are allocated IPv4 addresses.
This document describes a mechanism for dynamically provisioning
softwires created using DHCPv4 over DHCPv6 (DHCP 4o6), including
provisioning the client with the address of the softwire border
router (BR) and informing the service provider of client's binding
between the dynamically allocated IPv4 address and Port Set ID and
the IPv6 address that the softwire Initiator will use for accessing
IPv4-over-IPv6 services.
It is used with DHCP 4o6 message flows to communicate the binding
over the IPv6-only network. The service provider can then use this
binding information to provision other functional elements in their
network accordingly, e.g. using the client's binding information to
synchronise the binding table in the border router.
2. Applicability
The mechanism described in this document is only suitable for use for
provisioning softwire clients via DHCP 4o6. The options described
here are only applicable within the DHCP 4o6 message exchange
process. Current softwire technologies suitable for extending to
incorporate DHCPv4 over DHCPv6 with dynamic IPv4 address leasing
include [RFC7597] and [RFC7596].
3. 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].
4. Solution Overview
The solution in this document is intended for the dynamic
establishment of IPv4-over-IPv6 softwires. DHCP 4o6 [RFC7341]
supports dynamically allocating (shared) IPv4 address. For a
softwire to be successfully created, the IPv4 address has to be
linked to the client's IPv6 tunnel source address. Within this
process, the DHCP 4o6 client uses a DHCPv6 option to signal its
tunnel source IPv6 address to the DHCP 4o6 server so that the
operator's provisioning system can create the binding and configure
the tunnel concentrator accordingly.
Farrer, et al. Expires August 5, 2017 [Page 3]
Internet-Draft DHCP 4o6 SADDR option February 2017
Two new DHCPv6 options are defined in this memo:
OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR. They are
intended to be used alongside the normal DHCPv4 IPv4 address
allocation message flow in the context of DHCP 4o6. If a DHCP 4o6
client supports this mechanism, it MUST include the code of
OPTION_DHCP4O6_SADDR_HINT in the Option Request Option (ORO)
[RFC3315] when requesting IPv4 configuration through DHCP 4o6.
The communication of parameters between the client and server is a
two-way process: OPTION_DHCP4O6_SADDR_HINT is optionally used by the
DHCP 4o6 server to indicate to the client a preferred IPv6 prefix for
binding the received IPv4 configuration and sourcing tunnel traffic.
This may be necessary if there are multiple IPv6 prefixes in use in
the customer network (e.g. ULAs), or if the specific IPv4-over-IPv6
transition mechanism requires the use of a particular prefix for any
reason. When the client has selected an IPv6 address to bind the
IPv4 configuration to, it passes the address back to the DHCP 4o6
server using OPTION_DHCP4O6_SADDR.
4.1. Provisioning the BR Address
To configure a softwire, the initiator also requires the IPv6 address
of the BR. Section 4.2 of [RFC7598] defines option 90
(OPTION_S46_BR) for this purpose, but mandates that the option can
only be used when encapsulated within one of the softwire container
options: OPTION_S46_CONT_MAPE, OPTION_S46_CONT_MAPT or
OPTION_S46_CONT_LW. From Section 3 of [RFC7598]:
"Softwire46 DHCPv6 clients that receive provisioning options that
are not encapsulated in container options MUST silently ignore
these options."
This document updates [RFC7598] to remove this restriction for DHCPv6
option 90 (OPTION_S46_BR) allowing it to appear directly within the
list of options in the client's ORO request and directly within
subsequent messages sent by the DHCPv6 server.
5. IPv6/IPv4 Binding Message Flow
The following diagram shows the client/server message flow and how
the options defined in this document are used. In each step, the
relevant DHCPv4 message is given above the arrow and the relevant
options below the arrow. All the DHCPv4 messages here are
encapsulated in DHCPv4-query or DHCPv4-response messages, and those
options are included in the 'options' field of the DHCPv4-query or
DHCPv4-response message.
Farrer, et al. Expires August 5, 2017 [Page 4]
Internet-Draft DHCP 4o6 SADDR option February 2017
DHCP 4o6 DHCP 4o6
Client Server
| DHCPDISCOVER (DHCPv4) |
Step 1 |----------------------------------------------------->|
| ORO with OPTION_S46_BR, |
| OPTION_DHCP4O6_SADDR_HINT(DHCPv6) |
| |
| DHCPOFFER (DHCPv4) |
Step 2 |<-----------------------------------------------------|
| OPTION_S46_BR, OPTION_DHCP4O6_SADDR_HINT |
| (cipv6-prefix-hint with service provider's |
| preferred prefix) (DHCPv6) |
| |
| DHCPREQUEST (DHCPv4) |
Step 3 |----------------------------------------------------->|
| OPTION_S46_BR, |
| OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with |
| client's bound /128 IPv6 address) (DHCPv6) |
| |
| DHCPACK (DHCPv4) |
Step 4 |<-----------------------------------------------------|
| OPTION_S46_BR, |
| OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with |
| client's bound /128 IPv6 prefix) (DHCPv6) |
| |
IPv6/IPv4 Binding Message Flow
A client attempting dynamic softwire configuration includes the
option code for OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT in the
DHCPv6 ORO in all DHCPv4-query messages it sends.
When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD
include OPTION_S46_BR. It MAY also include
OPTION_DHCP4O6_SADDR_HINT, which is used to indicate a preferred
prefix that the client should use to bind IPv4 configuration to. If
this option is received, the client MUST perform a longest prefix
match between cipv6-prefix-hint and all prefixes/addresses in use on
the device. If a match is found, the selected prefix MUST then be
used to bind the received IPv4 configuration to and source the tunnel
from. If no match is found, or the client doesn't receive
OPTION_DHCP4O6_SADDR_HINT the client MAY select any valid IPv6
address to use as the tunnel source.
Once the client has selected which prefix it will use, it MAY use
either an existing IPv6 address that is already configured on an
interface, or create a new address specifically for use as the
Farrer, et al. Expires August 5, 2017 [Page 5]
Internet-Draft DHCP 4o6 SADDR option February 2017
softwire source address (e.g. using an Interface Identifier
constructed as per Section 6 of [RFC7597]). If a new address is
being created, the client MUST complete configuration of the new
address, performing duplicate address detection (if required) before
proceeding to Step 3.
OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6
Server which IPv6 address the IPv4 configuration has been bound to.
The client MUST put the selected IPv6 softwire source address into
this option and include it in the DHCPv4-response message when it
sends the DHCPREQUEST message.
6. DHCPv6 Options
6.1. DHCPv4 over DHCPv6 Source Address Hint Option
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_DHCP4O6_SADDR_HINT | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|cipv6-hintlen | |
+-+-+-+-+-+-+-+-+ cipv6-prefix-hint .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1)
o option-length: 1 + length of cipv6-prefix-hint, specified in
bytes.
o cipv6-hintlen: 8-bit field expressing the bit mask length of the
IPv6 prefix specified in cipv6-prefix-hint. Valid values are 0 to
128.
o cipv6-prefix-hint: The IPv6 prefix indicating the preferred prefix
for the client to bind the received IPv4 configuration to. The
length is (cipv6-hintlen + 7) / 8. The field is padded on the
right with zero bits up to the nearest octet boundary when cipv6-
prefix-hint is not evenly divisible by 8.
OPTION_DHCP4O6_SADDR_HINT is a singleton. Servers MUST NOT send more
than one instance of the OPTION_DHCP4O6_SADDR_HINT option.
6.1.1. Client Option Validation Behavior
On receipt of the OPTION_DHCP4O6_SADDR_HINT option, the client makes
the following validation checks:
o The received cipv6-hintlen value is not larger than 128.
Farrer, et al. Expires August 5, 2017 [Page 6]
Internet-Draft DHCP 4o6 SADDR option February 2017
o The received cipv6-hintlen value is not larger than the number of
bytes sent in the cipv6-prefix-hint field. (e.g. the cipv6-hintlen
is 128 but the cipv6-prefix-hint has only 8 bytes).
For either of these cases the receiver MAY either discard the option
and proceed to attempt configuration as if the option had not been
received, or attempt to use the received values for the long prefix
match anyway.
The receiver MUST only use bits the cipv6-prefix-hint field up to the
value specified in the cipv6-hintlen when performing the longest
prefix match. cipv6-prefix-hint bits beyond this value MUST be
ignored.
6.2. 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_DHCP4O6_SADDR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ cipv6-src-address +
. (128 bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_DHCP4O6_SADDR (TBA2)
o option-length: 16.
o cipv6-src-address: 16 bytes long; The IPv6 address that the client
has bound the allocated IPv4 configuration to.
7. Security Considerations
Security considerations which are applicable to [RFC7341] are also
applicable here.
8. IANA Considerations
IANA is requested to allocate a DHCPv6 option code for
OPTION_DHCP4O6_SADDR_HINT and a DHCPv4 option code for
OPTION_DHCP4O6_SADDR.
Farrer, et al. Expires August 5, 2017 [Page 7]
Internet-Draft DHCP 4o6 SADDR option February 2017
9. Acknowledgements
The authors would like to thank Ted Lemon, Lishan Li and Tatuya
Jinmei for their contributions and comments.
10. References
10.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>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
RFC 7341, DOI 10.17487/RFC7341, August 2014,
<http://www.rfc-editor.org/info/rfc7341>.
10.2. Informative References
[I-D.farrer-softwire-br-multiendpoints]
Farrer, I. and Q. Sun, "Multiple BR Tunnel Endpoint
Addresses", draft-farrer-softwire-br-multiendpoints-01
(work in progress), July 2015.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[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>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
Farrer, et al. Expires August 5, 2017 [Page 8]
Internet-Draft DHCP 4o6 SADDR option February 2017
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
Configuration of Softwire Address and Port-Mapped
Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
<http://www.rfc-editor.org/info/rfc7598>.
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.csnet.thu@gmail.com
Yong Cui
Tsinghua University
Beijing 100084
P.R. China
Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn
Linhui Sun
Tsinghua University
Beijing 100084
P.R. China
Phone: +86-10-6278-5822
Email: lh.sunlinh@gmail.com
Farrer, et al. Expires August 5, 2017 [Page 9]
