draft-ietf-dhc-dhcp4o6-saddr-opt-00.txt   draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt 
DHCWG I. Farrer DHCWG I. Farrer
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Updates: RFC7598 (if approved) Q. Sun Updates: 7598 (if approved) Q. Sun
Intended status: Standards Track Y. Cui Intended status: Standards Track Y. Cui
Expires: September 10, 2017 L. Sun Expires: June 15, 2018 L. Sun
Tsinghua University Tsinghua University
March 9, 2017 December 12, 2017
DHCPv4 over DHCPv6 Source Address Option DHCPv4 over DHCPv6 Source Address Option
draft-ietf-dhc-dhcp4o6-saddr-opt-00 draft-ietf-dhc-dhcp4o6-saddr-opt-01
Abstract Abstract
DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically DHCPv4 over DHCPv6 is a mechanism for dynamically configuring IPv4
configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with
to function with some IPv4-over-IPv6 softwire mechanisms and some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the
deployment scenarios, the operator must learn the /128 IPv6 address operator needs to know the /128 IPv6 address that the client will use
that the client will use as the source of IPv4-in-IPv6 tunnel. This as the source of IPv4-in-IPv6 softwire tunnel. This address, in
address, in conjunction with the IPv4 address and the Port Set ID conjunction with the clients IPv4 address and (in some deployments),
allocated to the DHCP 4o6 client are used to create a binding table the Port Set ID are used to create a binding table entry in the
entry in the softwire tunnel concentrator. This memo defines two operator's softwire tunnel concentrator. This memo defines a DHCPv6
DHCPv6 options used to communicate the source tunnel IPv6 address option to convey IPv6 parameters for establishing the softwire tunnel
between the DHCP 4o6 client and server. It also describes a method and a DHCPv4 option (to be used only with DHCP 4o6) to communicate
for configuring the client with the IPv6 address of the border router the source tunnel IPv6 address between the DHCP 4o6 client and
so that the softwire can be established. It is designed to work in server. It is designed to work in conjunction with the IPv4 address
conjunction with the IPv4 address allocation process. allocation process. This document updates "DHCPv6 Options for
Configuration of Softwire Address and Port-Mapped Clients" to allow
the DHCPv6 option OPTION_S46_BR(90) to appear outside of DHCPv6
softwire container options.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2017. This Internet-Draft will expire on June 15, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Provisioning the BR Address . . . . . . . . . . . . . . . 4 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 4
5. IPv6/IPv4 Binding Message Flow . . . . . . . . . . . . . . . 4 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 5
6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 6 6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. DHCPv4 over DHCPv6 Source Address Hint Option . . . . . . 6 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 6
6.1.1. Client Option Validation Behavior . . . . . . . . . . 6 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option . . . . 7
6.2. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . 7 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7.1. Client Initialization . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.2. Renewing or Rebinding the IPv4 Address Lease and
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 Softwire Source Address . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.3. Releasing the IPv4 Address Lease and Softwire
10.2. Informative References . . . . . . . . . . . . . . . . . 8 Source Address . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 9
7.5. Client and Server Softwire Source Address Mismatch . . . 10
7.6. Use With Dynamic, Shared IPv4 Addresses . . . . . . . . . 10
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Deterministic IPv4-over-IPv6 transition technologies require that Deterministic IPv4-over-IPv6 transition technologies require that
elements are pre-configured with binding rules for routing traffic to elements are pre-configured with binding rules for routing traffic to
clients. This places a constraint on the location of the client's clients. This places a constraint on the choice of address used as
tunnel endpoint: The tunnel endpoint has to be a pre-determined the client's softwire source address: it must use a pre-determined
prefix which is usually be configured on the home gateway device. prefix which is usually configured on the home gateway device.
[RFC7597] describes a DHCPv6 based mechanism for provisioning such [RFC7597] describes a DHCPv6 based mechanism for provisioning such
deterministic softwires. deterministic softwires.
A dynamic provisioning model, such as using DHCPv4 over DHCPv6 A dynamic provisioning model, such as using DHCPv4 over DHCPv6
[RFC7341] allows much more flexibility in the location of the IPv4- [RFC7341] (DHCP 4o6) allows much more flexibility in the location of
over-IPv6 tunnel endpoint, as the IPv6 address is dynamically the IPv4-over-IPv6 softwire source address. In this model, the IPv6
signalled back to the service provider so that the corresponding address is dynamically communicated back to the service provider
tunnel configuration in the border router (BR) can be created. The allowing the corresponding softwire configuration to be created in
DHCP 4o6 client and tunnel client could be run on end devices the border router (BR).
The DHCP 4o6 client and softwire client could be run on end devices
attached to any routable IPv6 prefix allocated to an end-user, attached to any routable IPv6 prefix allocated to an end-user,
located anywhere within an arbitrary home network topology. Dynamic located anywhere within an arbitrary home network topology. Dynamic
allocation also helps to optimize IPv4 resource usage as only clients allocation also helps to optimize IPv4 resource usage as only clients
which are currently active are allocated IPv4 addresses. which are actively renewing their IPv4 lease hold on to the address.
This document describes a mechanism for dynamically provisioning This document describes a mechanism for dynamically provisioning
softwires created using DHCPv4 over DHCPv6 (DHCP 4o6), including softwires created using DHCP 4o6, including provisioning the client
provisioning the client with the address of the softwire border with the address of the softwire border router (BR) and informing the
router (BR) and informing the service provider of client's binding service provider of client's binding between the dynamically
between the dynamically allocated IPv4 address and Port Set ID and allocated IPv4 address and Port Set ID and the IPv6 address that the
the IPv6 address that the softwire Initiator will use for accessing softwire Initiator will use for accessing IPv4-over-IPv6 services.
IPv4-over-IPv6 services.
It is used with DHCP 4o6 message flows to communicate the binding The mechanism operates alongside the DHCP 4o6 message flows to
over the IPv6-only network. The service provider can then use this communicate the binding information over the IPv6-only network. The
binding information to provision other functional elements in their DHCP 4o6 server provides a single point in the network which holds
network accordingly, e.g. using the client's binding information to the current client binding information. The service provider can
synchronise the binding table in the border router. then use this binding information to provision other functional
elements, such as the BR(s).
2. Applicability 2. Applicability
The mechanism described in this document is only suitable for use for The mechanism described in this document is only suitable for use for
provisioning softwire clients via DHCP 4o6. The options described provisioning softwire clients via DHCP 4o6. The options described
here are only applicable within the DHCP 4o6 message exchange here are only applicable within the DHCP 4o6 message exchange
process. Current softwire technologies suitable for extending to process. Current softwire technologies suitable for extending to
incorporate DHCPv4 over DHCPv6 with dynamic IPv4 address leasing incorporate DHCP 4o6 with dynamic IPv4 address leasing include
include [RFC7597] and [RFC7596]. [RFC7597] and [RFC7596].
3. Requirements Language 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
4. Solution Overview 4. Solution Overview
The solution in this document is intended for the dynamic In order to provision a softwire, both IPv6 and IPv4 configuration
establishment of IPv4-over-IPv6 softwires. DHCP 4o6 [RFC7341] needs to be passed to the client. To map this to the DHCP 4o6
supports dynamically allocating (shared) IPv4 address. For a configuration process, the IPv6 configuration is carried in DHCPv6
softwire to be successfully created, the IPv4 address has to be options carried inside the DHCPv6 message DHCPV4-RESPONSE(21) sent by
linked to the client's IPv6 tunnel source address. Within this the server. OPTION_S46_BR(90) is used to provision the remote IPv6
process, the DHCP 4o6 client uses a DHCPv6 option to signal its address for the softwire (see Section 4.1 below).
tunnel source IPv6 address to the DHCP 4o6 server so that the OPTION_S46_BIND_IPV6_PREFIX(TBD1), is optionally sent by the DHCP 4o6
operator's provisioning system can create the binding and configure server to indicate to the client a preferred IPv6 prefix for binding
the tunnel concentrator accordingly. 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.
Two new DHCPv6 options are defined in this memo: IPv4 configuration is carried in DHCPv4 messages (inside the DHCP 4o6
OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR. They are option OPTION_DHCPV4_MSG(87)) using the mechanism described in
intended to be used alongside the normal DHCPv4 IPv4 address [RFC7341].
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 In order for the client to communicate the softwire source address, a
two-way process: OPTION_DHCP4O6_SADDR_HINT is optionally used by the new DHCPv4 option OPTION_DHCP4O6_S46_SADDR(TBD2) is defined in this
DHCP 4o6 server to indicate to the client a preferred IPv6 prefix for document. This is included in DHCPREQUEST messages sent by the
binding the received IPv4 configuration and sourcing tunnel traffic. client and is stored by the server for the lifetime of the IPv4
This may be necessary if there are multiple IPv6 prefixes in use in address lease.
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 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90)
To configure a softwire, the initiator also requires the IPv6 address Section 4.2 of [RFC7598] defines option OPTION_S46_BR(90) for
of the BR. Section 4.2 of [RFC7598] defines option 90 communicating remote softwire border relay(BR)'s' IPv6 address(es) to
(OPTION_S46_BR) for this purpose, but mandates that the option can a client, but mandates that the option can only be used when
only be used when encapsulated within one of the softwire container encapsulated within one of the softwire container options:
options: OPTION_S46_CONT_MAPE, OPTION_S46_CONT_MAPT or OPTION_S46_CONT_MAPE(94) or OPTION_S46_CONT_LW(96). From Section 3
OPTION_S46_CONT_LW. From Section 3 of [RFC7598]: of [RFC7598]:
"Softwire46 DHCPv6 clients that receive provisioning options that "Softwire46 DHCPv6 clients that receive provisioning options that
are not encapsulated in container options MUST silently ignore are not encapsulated in container options MUST silently ignore
these options." these options."
This document updates [RFC7598] to remove this restriction for DHCPv6 This document updates [RFC7598], removing this restriction for
option 90 (OPTION_S46_BR) allowing it to appear directly within the OPTION_S46_BR(90), allowing it to be enumerated in the client's ORO
list of options in the client's ORO request and directly within request and appear directly within subsequent messages sent by the
subsequent messages sent by the DHCPv6 server. DHCPv6 server.
5. IPv6/IPv4 Binding Message Flow 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow
The following diagram shows the client/server message flow and how The following diagram shows the relevant extensions to the DHCP 4o6
the options defined in this document are used. In each step, the IPv4 allocation client/server message flow for the softwire source
relevant DHCPv4 message is given above the arrow and the relevant address function.
options below the arrow. All the DHCPv4 messages here are
encapsulated in DHCPv4-query or DHCPv4-response messages, and those In each step, the DHCPv6 portion of the message and any relevant
options are included in the 'options' field of the DHCPv4-query or option is shown above the arrow. The DHCP 4o6 content of the message
DHCPv4-response message. and its relevant options are below the arrow. All the DHCPv4
messages are encapsulated in DHCPV4-QUERY(20) or DHCPV4-RESPONSE(21)
messages. Where relevant, the necessary options and their contents
are shown.
DHCP 4o6 DHCP 4o6 DHCP 4o6 DHCP 4o6
Client Server Client Server
| DHCPDISCOVER (DHCPv4) | | |
| DHCPv6 - DHCPV4-QUERY message containing |
| OPTION_ORO(6) listing (90, TBD1) |
Step 1 |----------------------------------------------------->| Step 1 |----------------------------------------------------->|
| ORO with OPTION_S46_BR, | | DHCPv4 - DHCPDISCOVER message |
| OPTION_DHCP4O6_SADDR_HINT(DHCPv6) |
| | | |
| DHCPOFFER (DHCPv4) | | |
| DHCPv6 - DHCPV4-RESPONSE message containing |
| OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) |
| (bind-ipv6-prefix with service provider's |
| preferred prefix) |
Step 2 |<-----------------------------------------------------| Step 2 |<-----------------------------------------------------|
| OPTION_S46_BR, OPTION_DHCP4O6_SADDR_HINT | | DHCPv4 - DHCPOFFER message |
| (cipv6-prefix-hint with service provider's |
| preferred prefix) (DHCPv6) |
| | | |
| DHCPREQUEST (DHCPv4) | | |
| DHCPv6 - DHCPV4-QUERY message |
Step 3 |----------------------------------------------------->| Step 3 |----------------------------------------------------->|
| OPTION_S46_BR, | | DHCPv4 - DHCPREQUEST message containing |
| OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address |
| client's bound /128 IPv6 address) (DHCPv6) | |with client's bound /128 IPv6 softwire source address)|
| | | |
| DHCPACK (DHCPv4) | | |
| DHCPv6 - DHCPV4-RESPONSE message |
Step 4 |<-----------------------------------------------------| Step 4 |<-----------------------------------------------------|
| OPTION_S46_BR, | | DHCPv4 - DHCPACK message containing |
| OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address |
| client's bound /128 IPv6 prefix) (DHCPv6) | |with client's bound /128 IPv6 softwire source address)|
| | | |
IPv6/IPv4 Binding Message Flow IPv6/IPv4 Binding Message Flow
A client attempting dynamic softwire configuration includes the Step 1 The client constructs a DHCPv6 'DHCPV4-QUERY(20)' message.
option code for OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT in the This message contains two options: DHCPv6 OPTION_ORO(6) and
DHCPv6 ORO in all DHCPv4-query messages it sends. OPTION_DHCPV4_MSG(87). OPTION_ORO lists '90' (OPTION_S46_BR)
and 'TBD1' (OPTION_S46_BIND_IPV6_PREFIX). OPTION_DHCPV4_MSG
contains a DHCP4 DHCPDISCOVER message.
When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD Step 2 The server responds with a DHCPv6 'DHCPV4-RESPONSE(20)'
include OPTION_S46_BR. It MAY also include message. This message contains OPTION_S46_BR(90) containing
OPTION_DHCP4O6_SADDR_HINT, which is used to indicate a preferred the IPv6 address of the BR for the client's softwire
prefix that the client should use to bind IPv4 configuration to. If configuration. The message may also, optionally contain
this option is received, the client MUST perform a longest prefix OPTION_S46_BIND_IPV6_PREFIX(TBD1). OPTION_DHCPV4_MSG
match between cipv6-prefix-hint and all prefixes/addresses in use on contains a DHCP4 DHCPOFFER message.
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 Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message
either an existing IPv6 address that is already configured on an containing a DHCP4 DHCPREQUEST message with
interface, or create a new address specifically for use as the OPTION_DHCP4O6_S46_SADDR(TBD2) with the IPv6 address which
softwire source address (e.g. using an Interface Identifier the client will use as its softwire source address.
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 Step 4 The server sends a DHCPv6 'DHCPV4-RESPONSE(20)' message.
Server which IPv6 address the IPv4 configuration has been bound to. OPTION_DHCPV4_MSG contains a DHCP4 DHCPACK message.
The client MUST put the selected IPv6 softwire source address into OPTION_DHCP4O6_S46_SADDR with the client's softwire source
this option and include it in the DHCPv4-response message when it address is included.
sends the DHCPREQUEST message.
6. DHCPv6 Options 6. DHCP Options
6.1. DHCPv4 over DHCPv6 Source Address Hint Option 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option
0 1 2 3 The format of DHCPv6 Source Binding Prefix hint option is as follows:
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) 0 1 2 3
o option-length: 1 + length of cipv6-prefix-hint, specified in 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
bytes. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o cipv6-hintlen: 8-bit field expressing the bit mask length of the | OPTION_S46_BIND_IPV6_PREFIX | option-length |
IPv6 prefix specified in cipv6-prefix-hint. Valid values are 0 to +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|bindprefix6-len| |
+-+-+-+-+-+-+-+-+ bind-ipv6-prefix .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of OPTION_S46_BIND_IPV6_PREFIX
o option-code: OPTION_S46_BIND_IPV6_PREFIX (TBA1)
o option-length: 1 + length of bind-ipv6-prefix, specified in bytes.
o bindprefix6-len: 8-bit field expressing the bit mask length of the
IPv6 prefix specified in bind-ipv6-prefix. Valid values are 0 to
128. 128.
o cipv6-prefix-hint: The IPv6 prefix indicating the preferred prefix o bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix
for the client to bind the received IPv4 configuration to. The for the client to bind the received IPv4 configuration to. The
length is (cipv6-hintlen + 7) / 8. The field is padded on the length is (bindprefix6-len + 7) / 8. The field is padded on the
right with zero bits up to the nearest octet boundary when cipv6- right with zero bits up to the nearest octet boundary when bind-
prefix-hint is not evenly divisible by 8. ipv6-prefix is not evenly divisible by 8.
OPTION_DHCP4O6_SADDR_HINT is a singleton. Servers MUST NOT send more OPTION_S46_BIND_IPV6_PREFIX is a singleton. Servers MUST NOT send
than one instance of the OPTION_DHCP4O6_SADDR_HINT option. more than one instance of the OPTION_S46_BIND_IPV6_PREFIX option.
6.1.1. Client Option Validation Behavior 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option
On receipt of the OPTION_DHCP4O6_SADDR_HINT option, the client makes The format of DHCPv4 over DHCPv6 softwire source address option is as
the following validation checks: follows:
o The received cipv6-hintlen value is not larger than 128. 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code (TBD) | option-length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ softwire-ipv6-src-address +
. (128 bits) .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o The received cipv6-hintlen value is not larger than the number of Format of OPTION_DHCP4O6_S46_SADDR
bytes sent in the cipv6-prefix-hint field. (e.g. the cipv6-hintlen
is 128 but the cipv6-prefix-hint has only 8 bytes). o option-code: OPTION_DHCP4O6_S46_SADDR (TBD2)
o option-length: 16.
o softwire-ipv6-src-address: 16 bytes long; The IPv6 address that
the client has bound the allocated IPv4 configuration to.
NB - The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the
DHCPv4 message 'chaddr' field, or the Client Identifier (61) option
in that it provides a lower-layer address which is unique that the
server can use for identifying the client. However, as both of these
are required to remain constant throughout the address lease
lifetime, they cannot be used with the mechanism described in this
document. This is because the client may only be able to construct
the IPv6 address to use as the source address after it has received
the first DHCP-RESPONSE message from the server containing
OPTION_S46_BIND_IPV6_PREFIX.
7. Client Behavior
A client requiring dynamic softwire configuration first enables DHCP
4o6 configuration using the method described in Section 5. of
[RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the
corresponding REPLY message, the client MAY continue with the
configuration process described below.
It is also a prerequisite that the client has already obtained a
suitable IPv6 prefix to use for its local softwire endpoint using
DHCPv6, SLAAC or another mechanism.
7.1. Client Initialization
When constructing the initial DHCP 4o6 DHCPDISCOVER message, the
client includes a DHCPv6 OPTION_ORO(6) within the options field of
the DHCP-QUERY message. OPTION_ORO contains the option codes for
OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (TBD1).
On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE
containing a DHCPOFFER message), the client checks the contents of
the DHCPv4-RESPONSE for the presence of a valid OPTION_S46_BR option.
If this option is not present, or does not contain at least one valid
IPv6 address for a BR, then the client MUST discard the message, as
without the address of the BR the client cannot configure the
softwire and so has no interface to request IPv4 configuration for.
The DHCP-RESPONSE message may also include
OPTION_S46_BIND_IPV6_PREFIX, which is used by the operator to
indicate a preferred prefix that the client should use to bind IPv4
configuration to. If received, the client first checks the option
according to Section 7.4. If valid, the client uses this prefix as
the 'IPv6 binding prefix' and follows to the process described in
Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to
construct the softwire. If no match is found, or the client doesn't
receive OPTION_S46_BIND_IPV6_PREFIX the client MAY select any valid
IPv6 prefix (of a suitable scope) to use as the tunnel source.
Once the client has selected a suitable prefix, 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 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.
The client then constructs a DHCPV4-QUERY message containing a DHCPv4
DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is included in the
options field of the DHCPREQUEST message with the IPv6 address of its
softwire source address in the softwire-ipv6-src-address field.
When the client receives a DHCPv4 DHCPACK message from the server, it
checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its
active softwire source address. If they match, the allocation
process has concluded. If there is a discrepancy then the process
described in Section 7.5 is followed.
7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source
Address
Whenever the client attempts to extend the lease time of the IPv4
address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its
softwire source address in the softwire-ipv6-src-address field MUST
be included in the DHCPREQUEST message.
7.2.1. Changing the Bound IPv6 Softwire Source Address
Across the lifetime of the leased IPv4 address, it is possible that
the client's IPv6 will change. E.g. if there is a flash IPv6 re-
numbering event.
In this situation, the client MUST inform the server of the new
address. This is done by sending a DHCPREQUEST message containing
OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address.
When the client receives a DHCPv4 DHCPACK message from the server, it
checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its
active softwire source address. If they match, the allocation
process has concluded. If there is a discrepancy then the process
described in Section 7.5 is followed.
7.3. Releasing the IPv4 Address Lease and Softwire Source Address
When the client no longer requires the IPv4 resource, it sends a
DHCPv4 DHCPRELEASE message to the server. As the options field is
unused in this message type, OPTION_DHCP4O6_S46_SADDR is not
included.
7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior
On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client
makes the following validation checks:
o The received bindprefix6-len value is not larger than 128.
o The received bindprefix6-len value is not larger than the number
of bytes sent in the bind-ipv6-prefix field. (e.g. the
bindprefix6-len is 128 but the bind-ipv6-prefix has only 8 bytes).
For either of these cases the receiver MAY either discard the option For either of these cases the receiver MAY either discard the option
and proceed to attempt configuration as if the option had not been and proceed to attempt configuration as if the option had not been
received, or attempt to use the received values for the long prefix received, or attempt to use the received values for the longest
match anyway. prefix match anyway.
The receiver MUST only use bits the cipv6-prefix-hint field up to the The receiver MUST only use bits the bind-ipv6-prefix field up to the
value specified in the cipv6-hintlen when performing the longest value specified in the bindprefix6-len when performing the longest
prefix match. cipv6-prefix-hint bits beyond this value MUST be prefix match. bind-ipv6-prefix bits beyond this value MUST be
ignored. ignored.
6.2. DHCPv4 over DHCPv6 Source Address Option 7.5. Client and Server Softwire Source Address Mismatch
The format of DHCPv4 over DHCPv6 Source address option is defined as If the client receives a DHCPACK message with an
follows: OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which differs
from its active softwire source address, the client MAY either:
0 1 2 3 o Wait for a randomised time interval and then resend a DHCPREQUEST
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 message with the correct softwire source address, OR
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Send a DHCPRELEASE message and re-start the process described in
| OPTION_DHCP4O6_SADDR | option-length | Section 7.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ cipv6-src-address +
. (128 bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_DHCP4O6_SADDR (TBA2) 7.6. Use With Dynamic, Shared IPv4 Addresses
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 [RFC7618]describes a mechanism for using DHCPv4 to distribute
dynamic, shared IPv4 addresses to clients. The mechanism described
in this document is compatible with IPv4 address sharing, and can be
enabled by following the process described in Section 6 of [RFC7618].
8. Server Behavior
Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the
server MUST also store the IPv6 softwire source address of the client
in the leasing address database, alongside the IPv4 address and
client identifier. An OPTION_DHCP4O6_S46_SADDR containing the bound
softwire source address MUST be sent in every DHCPACK message sent by
the server.
The binding entry between the client's IPv6 softwire source address
and the leased IPv4 address is valid as long as the IPv4 lease
remains valid.
8.1. Changing the Bound IPv6 Source Address
In the event that the server receives a DHCPREQUEST message for an
active IPv4 lease containing a OPTION_DHCP4O6_S46_SADDR with an IPv6
address which differs from the address which is currently stored, the
server updates the stored softwire source address with the new
address supplied by the client, and sends a DHCPACK message
containing the updated softwire source address in
OPTION_DHCP4O6_S46_SADDR.
9. Security Considerations
Security considerations which are applicable to [RFC7341] are also Security considerations which are applicable to [RFC7341] are also
applicable here. applicable here.
8. IANA Considerations 10. IANA Considerations
IANA is requested to allocate a DHCPv6 option code for IANA is requested to allocate a new DHCPv6 option code for
OPTION_DHCP4O6_SADDR_HINT and a DHCPv4 option code for OPTION_S46_BIND_IPV6_PREFIX from the DHCPv6 Option Codes registry and
OPTION_DHCP4O6_SADDR. a new DHCPv4 option code for OPTION_DHCP4O6_S46_SADDR from the BOOTP
Vendor Extensions and DHCP Options registry.
9. Acknowledgements 11. Acknowledgements
The authors would like to thank Ted Lemon, Lishan Li and Tatuya The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei
Jinmei for their contributions and comments. and Jonas Gorski for their contributions and comments.
10. References 12. References
10.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
RFC 7341, DOI 10.17487/RFC7341, August 2014, RFC 7341, DOI 10.17487/RFC7341, August 2014,
<http://www.rfc-editor.org/info/rfc7341>. <https://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, 12.2. Informative References
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. [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual- Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>. July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597, Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015, DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>. <https://www.rfc-editor.org/info/rfc7597>.
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
Configuration of Softwire Address and Port-Mapped Configuration of Softwire Address and Port-Mapped
Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,
<http://www.rfc-editor.org/info/rfc7598>. <https://www.rfc-editor.org/info/rfc7598>.
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
RFC 7618, DOI 10.17487/RFC7618, August 2015,
<https://www.rfc-editor.org/info/rfc7618>.
Authors' Addresses Authors' Addresses
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
CTO-ATI, Landgrabenweg 151 CTO-ATI, Landgrabenweg 151
Bonn, NRW 53227 Bonn, NRW 53227
Germany Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
 End of changes. 66 change blocks. 
225 lines changed or deleted 371 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/