draft-ietf-dhc-dhcp4o6-saddr-opt-07.txt   draft-ietf-dhc-dhcp4o6-saddr-opt-08.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: May 7, 2019 L. Sun Expires: May 16, 2019 L. Sun
Tsinghua University Tsinghua University
November 3, 2018 November 12, 2018
Softwire Provisioning using DHCPv4 Over DHCPv6 Softwire Provisioning using DHCPv4 Over DHCPv6
draft-ietf-dhc-dhcp4o6-saddr-opt-07 draft-ietf-dhc-dhcp4o6-saddr-opt-08
Abstract Abstract
DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically
configuring IPv4 for use as an over-the-top service in a IPv6-only configuring IPv4 for use as an over-the-top service in a IPv6-only
network. Softwires are an example of such a service. For DHCPv4 network. Softwires are an example of such a service. For DHCPv4
over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire
mechanisms and deployment scenarios (e.g., RFC7596 or RFC7597), the mechanisms and deployment scenarios (e.g., RFC7596 or RFC7597), the
operator needs to know the IPv6 address that the client will use as operator needs to know the IPv6 address that the client will use as
the source of IPv4-in-IPv6 softwire tunnel. This address, in the source of IPv4-in-IPv6 softwire tunnel. This address, in
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 May 7, 2019. This Internet-Draft will expire on May 16, 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
skipping to change at page 12, line 31 skipping to change at page 12, line 31
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 8.2. Handling Conflicts Between Client's Bound IPv6 Source Addresses
In order for traffic to be forwarded correctly, each CE's softwire In order for traffic to be forwarded correctly, each CE's softwire
IPv6 source addresses must be unique. To ensure this, on receipt of IPv6 source addresses must be unique. To ensure this, on receipt of
every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR, every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR,
the DHCP 4o6 server MUST check the received IPv6 address against all the DHCP 4o6 server MUST check the received IPv6 address against all
existing CE source addresses stored for active client IPv4 leases. existing CE source addresses stored for active client IPv4 leases.
If there is a match, then the client's source address MUST NOT be If there is a match for any active lease other than the lease
stored or updated. belonging to the client sending the DHCPREQUEST, then the client's
IPv6 source address MUST NOT be stored or updated.
Depending on where the client and server are in the address leasing Depending on where the client and server are in the address leasing
lifecycle, the DHCP 4o6 server then takes the following action: lifecycle, the DHCP 4o6 server then takes the following action:
o If the DHCP 4o6 does not have a current, active IPv4 address lease 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 for the client, then the DHCP address allocation process has not
been succesful. The server returns a DHCPNAK message to the been succesful. The server returns a DHCPNAK message to the
client. client.
o If the DHCP 4o6 does have a current, active IPv4 address lease, 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 then the source address update process (see Section 8.1) has not
skipping to change at page 13, line 21 skipping to change at page 13, line 21
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. This could be attempted in three ways: use by another client. This could be attempted in three ways:
1. One customer learning the active IPv4 address lease and client 1. One customer learning the active IPv4 address lease and client
identifier of another customer via snooping the DHCP4o6 message identifier of another customer via snooping the DHCP4o6 message
flow between the client and server. The mechanism described in flow between the client and server. The mechanism described in
this document is intended for use in a typical ISP network this document is intended for use in a typical ISP network
topology with a dedicated layer-2 access network per-client, topology with a dedicated layer-2 access network per-client,
meaning that snooping of another client's traffic is not meaning that snooping of another client's traffic is not
possible. If the access network is a shared medium then it possible. If the access network is a shared medium then
provisioning softwire clients using dynamic DHCP4o6 as described provisioning softwire clients using dynamic DHCP4o6 as described
here is NOT RECOMMENDED. here is NOT RECOMMENDED.
2. Learning the active IPv4 address lease and client identifier via 2. Learning the active IPv4 address lease and client identifier via
snooping the DHCP4o6 message flow between the client and server snooping the DHCP4o6 message flow between the client and server
in the aggregation or core ISP network. In this case, the in the aggregation or core ISP network. In this case, the
attacker requires a level of access to the ISP's infrastructure attacker requires a level of access to the ISP's infrastructure
that means they can already intercept or interfere with traffic that means they can already intercept or interfere with traffic
flows to the client. flows to the client.
3. An attacker could attempt to brute-force guessing the IPv4 lease 3. An attacker could attempt to brute-force guessing the IPv4 lease
address and client identifier tuple. The risk of this can be address and client identifier tuple. The risk of this can be
skipping to change at page 14, line 12 skipping to change at page 14, line 12
considerations and recommendations are also applicable to clients considerations and recommendations are also applicable to clients
implementing the mechanism described in this document. As DHCP4o6 implementing the mechanism described in this document. As DHCP4o6
only uses DHCPv6 as a stateless transport for DHCPv4 messages, the only uses DHCPv6 as a stateless transport for DHCPv4 messages, the
"Anonymity Profile for DHCPv4" described in Section 3 is most "Anonymity Profile for DHCPv4" described in Section 3 is most
relevant here. relevant here.
In addition to the considerations given in [RFC7844], the mechanism In addition to the considerations given in [RFC7844], the mechanism
that the client uses for constructing the interface identifier for that the client uses for constructing the interface identifier for
its IPv6 softwire source address (see Section 7.1), could result in its IPv6 softwire source address (see Section 7.1), could result in
the device being trackable across different networks and sessions, the device being trackable across different networks and sessions,
e.g., if the client's softwire IID is immutable. e.g., if the client's softwire Interface Identifier (IID) is
immutable.
This can be mitigated by constructing the softwire source IPv6 This can be mitigated by constructing the softwire source IPv6
address as per Section 6 of [RFC7597]. Here, the address' IID address as per Section 6 of [RFC7597]. Here, the address' IID
contains only the allocated IPv4 address (and port set identifier if contains only the allocated IPv4 address (and port set identifier if
[RFC7618] is being used). This means no additional client [RFC7618] is being used). This means no additional client
information is exposed to the DHCP4o6 server, and will also mean that 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 the IID will change as the leased IPv4 address changes (e.g., between
sessions when Section 3.5 of [RFC7844] is implemented). 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 and use the
following data when adding the option to the registry:
Value: TDB1
Description: OPTION_S46_BIND_IPV6_PREFIX
Client ORO: Yes
Singleton Option: Yes
Reference: this document
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 and use the following data when adding the option to the
registry:
Value: TDB2
Name: OPTION_DHCP4O6_S46_SADDR
Data Length: 16
Meaning: DHCPv4 over DHCPv6 Softwire Source Address Option
Reference: this document
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 maintained at
dhcpv6-parameters as follows: https://www.iana.org/assignments/dhcpv6-parameters as follows:
Old Entry: Old Entry:
Value: 90 Value: 90
Description: OPTION_S46_BR Description: OPTION_S46_BR
Client ORO: No Client ORO: No
Singleton Option: No Singleton Option: No
Reference: [RFC7598] Reference: [RFC7598]
New Entry: New Entry:
Value: 90 Value: 90
Description: OPTION_S46_BR Description: OPTION_S46_BR
Client ORO: Yes Client ORO: Yes
Singleton Option: No Singleton Option: No
Reference: [RFC7598] [RFCXXXX] Reference: [RFC7598], this document
IANA is also requested to make a new entry for
OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at
https://www.iana.org/assignments/dhcpv6-parameters:
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
 End of changes. 11 change blocks. 
23 lines changed or deleted 29 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/