draft-ietf-dhc-dhcp4o6-saddr-opt-06.txt   draft-ietf-dhc-dhcp4o6-saddr-opt-07.txt 
DHCWG I. Farrer DHCWG I. Farrer
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Updates: 7598 (if approved) Q. Sun Updates: 7598 (if approved) Q. Sun
Intended status: Standards Track Y. Cui Intended status: Standards Track Y. Cui
Expires: April 8, 2019 L. Sun Expires: May 7, 2019 L. Sun
Tsinghua University Tsinghua University
October 5, 2018 November 3, 2018
Softwire Provisioning using DHCPv4 Over DHCPv6 Softwire Provisioning using DHCPv4 Over DHCPv6
draft-ietf-dhc-dhcp4o6-saddr-opt-06 draft-ietf-dhc-dhcp4o6-saddr-opt-07
Abstract Abstract
DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically
configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 configuring IPv4 for use as an over-the-top service in a IPv6-only
(DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms network. Softwires are an example of such a service. For DHCPv4
and deployment scenarios (e.g., RFC7596 or RFC7597), the operator over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire
needs to know the IPv6 address that the client will use as the s mechanisms and deployment scenarios (e.g., RFC7596 or RFC7597), the
ource of IPv4-in-IPv6 softwire tunnel. This address, in conjunction operator needs to know the IPv6 address that the client will use as
with the client's IPv4 address, and (in some deployments) the Port the source of IPv4-in-IPv6 softwire tunnel. This address, in
Set ID are used to create a binding table entry in the operator's conjunction with the client's IPv4 address, and (in some deployments)
softwire tunnel concentrator. This memo defines a DHCPv6 option to the Port Set ID are used to create a binding table entry in the
convey IPv6 parameters for establishing the softwire tunnel and a operator's softwire tunnel concentrator. This memo defines a DHCPv6
DHCPv4 option (to be used only with DHCP 4o6) to communicate the option to convey IPv6 parameters for establishing the softwire tunnel
source tunnel IPv6 address between the DHCP 4o6 client and server. and a DHCPv4 option (to be used only with DHCP 4o6) to communicate
It is designed to work in conjunction with the IPv4 address the source tunnel IPv6 address between the DHCP 4o6 client and
server. It is designed to work in conjunction with the IPv4 address
allocation process. allocation process.
DHCPv6 Options for Configuration of Softwire Address and Port-Mapped DHCPv6 Options for Configuration of Softwire Address and Port-Mapped
Clients (RFC7598) describes a deterministic DHCPv6 based mechanism Clients (RFC7598) describes a deterministic DHCPv6 based mechanism
for provisioning softwires. This document updates "DHCPv6 Options for provisioning softwires. This document updates "DHCPv6 Options
for Configuration of Softwire Address and Port-Mapped Clients" for Configuration of Softwire Address and Port-Mapped Clients"
(RFC7598), allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 (RFC7598), allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6
client's Option Request Option (ORO) request and appear directly client's Option Request Option (ORO) request and appear directly
within subsequent messages sent by the DHCPv6 server. within subsequent messages sent by the DHCPv6 server.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 https://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 April 8, 2019. This Internet-Draft will expire on May 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 4 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 4
5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 5 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 5
6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7 6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7
6.2. DHCPv4 over DHCPv6 Softwire Source Address Option . . . . 7 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option . . . . 8
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Client Initialization . . . . . . . . . . . . . . . . . . 8 7.1. Client Initialization . . . . . . . . . . . . . . . . . . 9
7.2. Renewing or Rebinding the IPv4 Address Lease and 7.2. Renewing or Rebinding the IPv4 Address Lease and
Softwire Source Address . . . . . . . . . . . . . . . . . 9 Softwire Source Address . . . . . . . . . . . . . . . . . 10
7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10 7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10
7.3. Releasing the IPv4 Address Lease and Softwire 7.3. Releasing the IPv4 Address Lease and Softwire
Source Address . . . . . . . . . . . . . . . . . . . . . 10 Source Address . . . . . . . . . . . . . . . . . . . . . 10
7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 10 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 10
7.5. Client and Server Softwire Source Address Mismatch . . . 11 7.5. Client and Server Softwire Source Address Mismatch . . . 11
7.6. Use With Dynamic, Shared IPv4 Addresses . . . . . . . . . 11 7.6. Use With Dynamic, Shared IPv4 Addresses . . . . . . . . . 11
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 11 8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 12
8.2. Handling Conflicts Between Client's Bound IPv6
Source Addresses . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9.1. Client Privacy Considerations . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 choice of address used as clients. This places a constraint on the choice of address used as
the client's softwire source address: it must use a pre-determined the client's softwire source address: it must use a pre-determined
prefix which is usually configured on the home gateway device. prefix which is usually configured on the home gateway device.
[RFC7598] describes a DHCPv6 based mechanism for provisioning such [RFC7598] describes a DHCPv6 based mechanism for provisioning such
deterministic softwires. deterministic softwires.
skipping to change at page 4, line 11 skipping to change at page 4, line 17
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 DHCP 4o6 with dynamic IPv4 address leasing include incorporate DHCP 4o6 with dynamic IPv4 address leasing 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
4. Solution Overview 4. Solution Overview
In order to provision a softwire, both IPv6 and IPv4 configuration In order to provision a softwire, both IPv6 and IPv4 configuration
needs to be passed to the client. To map this to the DHCP 4o6 needs to be passed to the client. To map this to the DHCP 4o6
configuration process, the IPv6 configuration is carried in DHCPv6 configuration process, the IPv6 configuration is carried in DHCPv6
options [I-D.ietf-dhc-rfc3315bis], carried inside the DHCPv6 message options [I-D.ietf-dhc-rfc3315bis], carried inside the DHCPv6 message
DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used
to provision the remote IPv6 address for the softwire border router to provision the remote IPv6 address for the softwire border router
(see Section 4.1 below). OPTION_S46_BIND_IPV6_PREFIX (TBD1), is (see Section 4.1 below). OPTION_S46_BIND_IPV6_PREFIX (TBD1), is
skipping to change at page 6, line 20 skipping to change at page 6, line 20
Step 1 |----------------------------------------------------->| Step 1 |----------------------------------------------------->|
| DHCPv4 - DHCPDISCOVER message | | DHCPv4 - DHCPDISCOVER message |
| | | |
| | | |
| DHCPv6 - DHCPV4-RESPONSE message containing | | DHCPv6 - DHCPV4-RESPONSE message containing |
| OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) | | OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) |
| (bind-ipv6-prefix with service provider's | | (bind-ipv6-prefix with service provider's |
| preferred prefix) | | preferred prefix) |
Step 2 |<-----------------------------------------------------| Step 2 |<-----------------------------------------------------|
| DHCPv4 - DHCPOFFER message | | DHCPv4 - DHCPOFFER message |
| | | containing an available IPv4 address |
| | | |
| DHCPv6 - DHCPV4-QUERY message | | DHCPv6 - DHCPV4-QUERY message |
Step 3 |----------------------------------------------------->| Step 3 |----------------------------------------------------->|
| DHCPv4 - DHCPREQUEST message containing | | DHCPv4 - DHCPREQUEST message containing the |
| OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | | requested IPv4 address and OPTION_DHCP4O6_S46_SADDR |
| with client's bound IPv6 softwire source address) | | (softwire-ipv6-src-address with client's bound |
| IPv6 softwire source address) |
| | | |
| | | |
| DHCPv6 - DHCPV4-RESPONSE message | | DHCPv6 - DHCPV4-RESPONSE message |
Step 4 |<-----------------------------------------------------| Step 4 |<-----------------------------------------------------|
| DHCPv4 - DHCPACK message containing | | DHCPv4 - DHCPACK message containing |
| OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | | the leased IPv4 address and OPTION_DHCP4O6_S46_SADDR |
| with client's bound IPv6 softwire source address) | | (softwire-ipv6-src-address with client's bound |
| IPv6 softwire source address) |
| | | |
Figure 1: IPv6/IPv4 Binding Message Flow Figure 1: IPv6/IPv4 Binding Message Flow
Step 1 The client constructs a DHCPv6 'DHCPV4-QUERY(20)' message. Step 1 The client constructs a DHCPv6 'DHCPV4-QUERY(20)' message.
This message contains two options: DHCPv6 OPTION_ORO (6) and This message contains two options: DHCPv6 OPTION_ORO (6) and
OPTION_DHCPV4_MSG (87). OPTION_ORO lists '90' OPTION_DHCPV4_MSG (87). OPTION_ORO lists '90'
(OPTION_S46_BR) and 'TBD1' (OPTION_S46_BIND_IPV6_PREFIX). (OPTION_S46_BR) and 'TBD1' (OPTION_S46_BIND_IPV6_PREFIX).
OPTION_DHCPV4_MSG contains a DHCPv4 DHCPDISCOVER message. OPTION_DHCPV4_MSG contains a DHCPv4 DHCPDISCOVER message.
Step 2 The server responds with a DHCPv6 'DHCPV4-RESPONSE (21)' Step 2 The server responds with a DHCPv6 'DHCPV4-RESPONSE (21)'
message. This message contains OPTION_S46_BR (90) containing message. This message contains an OPTION_S46_BR (90)
the IPv6 address of the BR for the client's softwire containing the IPv6 address of the BR for the client's
configuration. The message may also optionally contain softwire configuration. The message may also optionally
OPTION_S46_BIND_IPV6_PREFIX (TBD1). OPTION_DHCPV4_MSG contain OPTION_S46_BIND_IPV6_PREFIX (TBD1).
contains a DHCPv4 DHCPOFFER message. OPTION_DHCPV4_MSG contains a DHCPv4 DHCPOFFER message. The
DHCPv4 message contains an available IPv4 address.
Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message
containing a DHCPv4 DHCPREQUEST message with containing a DHCPv4 DHCPREQUEST message with the requested
OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6 address which IPv4 address and OPTION_DHCP4O6_S46_SADDR (TBD2) with the
the client will use as its softwire source address. IPv6 address which the client will use as its softwire source
address.
Step 4 The server sends a DHCPv6 'DHCPV4-RESPONSE (21)' message. Step 4 The server sends a DHCPv6 'DHCPV4-RESPONSE (21)' message.
OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message. OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message with the
OPTION_DHCP4O6_S46_SADDR with the client's softwire source allocated IPv4 address. OPTION_DHCP4O6_S46_SADDR with the
address is included. client's bound softwire source address is included.
6. DHCP Options 6. DHCP Options
6.1. DHCPv6 Softwire Source Binding Prefix Hint Option 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option
The format of DHCPv6 Source Binding Prefix hint option is as follows: The format of DHCPv6 Source Binding Prefix hint option is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 41 skipping to change at page 8, line 46
OPTION_S46_BIND_IPV6_PREFIX. OPTION_S46_BIND_IPV6_PREFIX.
7. Client Behavior 7. Client Behavior
A client requiring dynamic softwire configuration first enables DHCP A client requiring dynamic softwire configuration first enables DHCP
4o6 configuration using the method described in Section 5 of 4o6 configuration using the method described in Section 5 of
[RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the [RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the
corresponding REPLY message, the client MAY continue with the corresponding REPLY message, the client MAY continue with the
configuration process described below. configuration process described below.
It is also a prerequisite that the client has already learned a Before the dynamic softwire configuration process can commence, the
suitable IPv6 prefix to use for its local softwire endpoint using client MUST be configured with a suitable IPv6 prefix to be used as
DHCPv6, RA/PIO or another mechanism. the local softwire endpoint. This could be obtained using DHCPv6,
RA/PIO or another mechanism.
7.1. Client Initialization 7.1. Client Initialization
When constructing the initial DHCP 4o6 DHCPDISCOVER message, the When constructing the initial DHCP 4o6 DHCPDISCOVER message, the
client includes a DHCPv6 OPTION_ORO (6) within the options field of client includes a DHCPv6 OPTION_ORO (6) within the options field of
the DHCP-QUERY message. OPTION_ORO contains the option codes for the DHCP-QUERY message. OPTION_ORO contains the option codes for
OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (TBD1). OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (TBD1).
On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE
containing a DHCPOFFER message), the client checks the contents of containing a DHCPOFFER message), the client checks the contents of
skipping to change at page 10, line 10 skipping to change at page 10, line 16
Address Address
Whenever the client attempts to extend the lease time of the IPv4 Whenever the client attempts to extend the lease time of the IPv4
address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its
softwire source address in the softwire-ipv6-src-address field MUST softwire source address in the softwire-ipv6-src-address field MUST
be included in the DHCPREQUEST message. be included in the DHCPREQUEST message.
7.2.1. Changing the Bound IPv6 Softwire Source Address 7.2.1. Changing the Bound IPv6 Softwire Source Address
Across the lifetime of the leased IPv4 address, it is possible that Across the lifetime of the leased IPv4 address, it is possible that
the client's IPv6 will change. E.g., if there is an IPv6 re- the client's IPv6 address will change, e.g., if there is an IPv6 re-
numbering event. numbering event.
In this situation, the client MUST inform the server of the new In this situation, the client MUST inform the server of the new
address. This is done by sending a DHCPREQUEST message containing address. This is done by sending a DHCPREQUEST message containing
OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address. OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address.
When the client receives a DHCPv4 DHCPACK message from the server, it When the client receives a DHCPv4 DHCPACK message from the server, it
checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its
active softwire source address. If they match, the allocation active softwire source address. If they match, the allocation
process has concluded. If there is a discrepancy then the process process has concluded. If there is a discrepancy then the process
skipping to change at page 11, line 36 skipping to change at page 11, line 43
[RFC7618] describes a mechanism for using DHCPv4 to distribute [RFC7618] describes a mechanism for using DHCPv4 to distribute
dynamic, shared IPv4 addresses to clients. The mechanism described dynamic, shared IPv4 addresses to clients. The mechanism described
in this document is compatible with IPv4 address sharing, and can be in this document is compatible with IPv4 address sharing, and can be
enabled by following the process described in Section 6 of [RFC7618]. enabled by following the process described in Section 6 of [RFC7618].
8. Server Behavior 8. Server Behavior
Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the
server MUST also store the IPv6 softwire source address of the client server MUST also store the IPv6 softwire source address of the client
in the leasing address database, alongside the IPv4 address and in the leasing address database, alongside the IPv4 address and
client identifier. An OPTION_DHCP4O6_S46_SADDR containing the bound client identifier.
softwire source address MUST be sent in every DHCPACK message sent by
the server. 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 The binding entry between the client's IPv6 softwire source address
and the leased IPv4 address is valid as long as the IPv4 lease and the leased IPv4 address is valid as long as the IPv4 lease
remains valid. remains valid.
8.1. Changing the Bound IPv6 Source Address 8.1. Changing the Bound IPv6 Source Address
In the event that the server receives a DHCPREQUEST message for an In the event that the server receives a DHCPREQUEST message for an
active IPv4 lease containing a OPTION_DHCP4O6_S46_SADDR with an IPv6 active IPv4 lease containing a OPTION_DHCP4O6_S46_SADDR with an IPv6
address which differs from the address which is currently stored, the address which differs from the address which is currently stored, the
skipping to change at page 12, line 16 skipping to change at page 12, line 24
The server MAY implement a policy enforcing a minimum time interval The server MAY implement a policy enforcing a minimum time interval
between a client updating its softwire source IPv6 address. If a between a client updating its softwire source IPv6 address. If a
client attempts to update the softwire source IPv6 address before the client attempts to update the softwire source IPv6 address before the
minimum time has expired, the server can either silently drop the minimum time has expired, the server can either silently drop the
client's message or send back a DHCPACK message containing the client's message or send back a DHCPACK message containing the
existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. If existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. If
implemented, the default minimum client source address update implemented, the default minimum client source address update
interval is 60 seconds. interval is 60 seconds.
8.2. Handling Conflicts Between Client's Bound IPv6 Source Addresses
In order for traffic to be forwarded correctly, each CE's softwire
IPv6 source addresses must be unique. To ensure this, on receipt of
every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR,
the DHCP 4o6 server MUST check the received IPv6 address against all
existing CE source addresses stored for active client IPv4 leases.
If there is a match, then the client's source address MUST NOT be
stored or updated.
Depending on where the client and server are in the address leasing
lifecycle, the DHCP 4o6 server then takes the following action:
o If the DHCP 4o6 does not have a current, active IPv4 address lease
for the client, then the DHCP address allocation process has not
been succesful. The server returns a DHCPNAK message to the
client.
o If the DHCP 4o6 does have a current, active IPv4 address lease,
then the source address update process (see Section 8.1) has not
been successful. The DHCP 4o6 server can either silently drop the
client's message or return a DHCPACK message containing the
existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR.
9. Security Considerations 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.
A rogue client could attempt to use the mechanism described in A rogue client could attempt to use the mechanism described in
Section 7.2.1 to redirect IPv4 traffic intended for another client to Section 7.2.1 to redirect IPv4 traffic intended for another client to
itself. This would be performed by sending a DHCPREQUEST message for itself. This would be performed by sending a DHCPREQUEST message for
another client's active IPv4 lease containing the attacker's softwire another client's active IPv4 lease containing the attacker's softwire
IPv6 address in OPTION_DHCP4O6_S46_SADDR. IPv6 address in OPTION_DHCP4O6_S46_SADDR.
For such an attack to be effective, the attacker would need to know For such an attack to be effective, the attacker would need to know
both the client identifier and active IPv4 address lease currently in both the client identifier and active IPv4 address lease currently in
use by another client. The risk of this can be reduced by using a use by another client. This could be attempted in three ways:
client identifier format which is not easily guessable, e.g., by
including a time component for when the client identifier was 1. One customer learning the active IPv4 address lease and client
generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2). identifier of another customer via snooping the DHCP4o6 message
flow between the client and server. The mechanism described in
this document is intended for use in a typical ISP network
topology with a dedicated layer-2 access network per-client,
meaning that snooping of another client's traffic is not
possible. If the access network is a shared medium then it
provisioning softwire clients using dynamic DHCP4o6 as described
here is NOT RECOMMENDED.
2. Learning the active IPv4 address lease and client identifier via
snooping the DHCP4o6 message flow between the client and server
in the aggregation or core ISP network. In this case, the
attacker requires a level of access to the ISP's infrastructure
that means they can already intercept or interfere with traffic
flows to the client.
3. An attacker could attempt to brute-force guessing the IPv4 lease
address and client identifier tuple. The risk of this can be
reduced by using a client identifier format which is not easily
guessable, e.g., by using a random based client identifier (see
[RFC7844] Section 3.5).
An attacker could attempt to redirect existing flows to a client
unable to process the traffic. This type of attack can be prevented
by implementing [BCP38] network ingress filtering in conjunction with
the BR source address validation processes described in [RFC7596]
Section 5.2 and [RFC7597] Section 8.1.
A client may attempt to overload the server by sending multiple A client may attempt to overload the server by sending multiple
source address update messages (see Section 7.2.1) in a short time source address update messages (see Section 7.2.1) in a short time
frame. This risk can be reduced by implementing a server policy frame. This risk can be reduced by implementing a server policy
enforcing a minimum time interval between client address changes as enforcing a minimum time interval between client address changes as
described in Section 8.1. described in Section 8.1.
9.1. Client Privacy Considerations
[RFC7844] describes anonymity profiles for DHCP clients. These
considerations and recommendations are also applicable to clients
implementing the mechanism described in this document. As DHCP4o6
only uses DHCPv6 as a stateless transport for DHCPv4 messages, the
"Anonymity Profile for DHCPv4" described in Section 3 is most
relevant here.
In addition to the considerations given in [RFC7844], the mechanism
that the client uses for constructing the interface identifier for
its IPv6 softwire source address (see Section 7.1), could result in
the device being trackable across different networks and sessions,
e.g., if the client's softwire IID is immutable.
This can be mitigated by constructing the softwire source IPv6
address as per Section 6 of [RFC7597]. Here, the address' IID
contains only the allocated IPv4 address (and port set identifier if
[RFC7618] is being used). This means no additional client
information is exposed to the DHCP4o6 server, and will also mean that
the IID will change as the leased IPv4 address changes (e.g., between
sessions when Section 3.5 of [RFC7844] is implemented).
10. IANA Considerations 10. IANA Considerations
IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX (TBD1) IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX (TBD1)
option code from the DHCPv6 "Option Codes" registry maintained at option code from the DHCPv6 "Option Codes" registry maintained at
http://www.iana.org/assignments/dhcpv6-parameters. http://www.iana.org/assignments/dhcpv6-parameters.
IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR (TBD2) IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR (TBD2)
option code from the "BOOTP Vendor Extensions and DHCP Options" option code from the "BOOTP Vendor Extensions and DHCP Options"
registry maintained at http://www.iana.org/assignments/bootp-dhcp- registry maintained at http://www.iana.org/assignments/bootp-dhcp-
parameters. parameters.
IANA is requested to update the entry for DHCPv6 Option S46_BR (90) IANA is requested to update the entry for DHCPv6 Option S46_BR (90)
in the Option Codes table at https://www.iana.org/assignments/ in the Option Codes table at https://www.iana.org/assignments/
dhcpv6-parameters as follows: dhcpv6-parameters as follows:
Old entry: Old Entry:
| 90 | S46_BR | No | No | Value: 90
Description: OPTION_S46_BR
Client ORO: No
Singleton Option: No
Reference: [RFC7598]
New entry: New Entry:
| 90 | S46_BR | Yes | No | Value: 90
Description: OPTION_S46_BR
Client ORO: Yes
Singleton Option: No
Reference: [RFC7598] [RFCXXXX]
IANA is also requested to make a new entry for IANA is also requested to make a new entry for
OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at
https://www.iana.org/assignments/dhcpv6-parameters: https://www.iana.org/assignments/dhcpv6-parameters:
| TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes | Yes | Value: TDB1
Description: OPTION_S46_BIND_IPV6_PREFIX
Client ORO: Yes
Singleton Option: Yes
Reference: [RFCXXXX]
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei, The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei,
Jonas Gorski and Razvan Becheriu for their contributions and Jonas Gorski and Razvan Becheriu for their contributions and
comments. comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
skipping to change at page 14, line 11 skipping to change at page 16, line 5
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,
<https://www.rfc-editor.org/info/rfc7341>. <https://www.rfc-editor.org/info/rfc7341>.
[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,
<https://www.rfc-editor.org/info/rfc7598>. <https://www.rfc-editor.org/info/rfc7598>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[BCP38] IETF, "Network Ingress Filtering: Defeating Denial of
Service Attacks which employ IP Source Address Spoofing
https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[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, <https://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,
<https://www.rfc-editor.org/info/rfc7597>. <https://www.rfc-editor.org/info/rfc7597>.
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
RFC 7618, DOI 10.17487/RFC7618, August 2015, RFC 7618, DOI 10.17487/RFC7618, August 2015,
<https://www.rfc-editor.org/info/rfc7618>. <https://www.rfc-editor.org/info/rfc7618>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>.
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
Qi Sun Qi Sun
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: sunqi.ietf@gmail.com Email: sunqi.ietf@gmail.com
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6260-3059 Phone: +86-10-6260-3059
Email: yong@csnet1.cs.tsinghua.edu.cn Email: yong@csnet1.cs.tsinghua.edu.cn
Linhui Sun Linhui Sun
Tsinghua University Tsinghua University
 End of changes. 34 change blocks. 
63 lines changed or deleted 175 lines changed or added

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