< draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt   draft-jabley-dnsext-eui48-eui64-rrtypes-07.txt >
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft TekSavvy Solutions, Inc. Internet-Draft TekSavvy Solutions, Inc.
Intended status: Standards Track April 23, 2013 Intended status: Informational August 15, 2013
Expires: October 25, 2013 Expires: February 16, 2014
Resource Records for EUI-48 and EUI-64 Addresses in the DNS Resource Records for EUI-48 and EUI-64 Addresses in the DNS
draft-jabley-dnsext-eui48-eui64-rrtypes-03 draft-jabley-dnsext-eui48-eui64-rrtypes-07
Abstract Abstract
48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended 48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended
Unique Identifiers (EUI-64) are address formats specified by the IEEE Unique Identifiers (EUI-64) are address formats specified by the IEEE
for use in various layer-2 networks, e.g. ethernet. for use in various layer-2 networks, e.g. Ethernet.
This document defines two new DNS resource record types, EUI48 and This document describes two new DNS resource record types, EUI48 and
EUI64, for encoding ethernet addresses in the DNS. EUI64, for encoding Ethernet addresses in the DNS.
This document describes potentially severe privacy implications
resulting from indiscriminate publication of link-layer addresses in
the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the
public DNS. This document specifies an interoperable encoding of
these address types for use in private DNS namespaces, where the
privacy concerns can be constrained and mitigated.
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 http://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 October 25, 2013. This Internet-Draft will expire on February 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 (http://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 2, line 13 skipping to change at page 2, line 20
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The EUI48 Resource Record . . . . . . . . . . . . . . . . . . 5 3. The EUI48 Resource Record . . . . . . . . . . . . . . . . . . 5
3.1. EUI48 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 3.1. EUI48 RDATA Wire Format . . . . . . . . . . . . . . . . . 5
3.2. EUI48 RR Presentation Format . . . . . . . . . . . . . . . 5 3.2. EUI48 RR Presentation Format . . . . . . . . . . . . . . . 5
3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The EUI64 Resource Record . . . . . . . . . . . . . . . . . . 6 4. The EUI64 Resource Record . . . . . . . . . . . . . . . . . . 6
4.1. EUI64 RDATA Wire Format . . . . . . . . . . . . . . . . . 6 4.1. EUI64 RDATA Wire Format . . . . . . . . . . . . . . . . . 6
4.2. EUI64 RR Presentation Format . . . . . . . . . . . . . . . 6 4.2. EUI64 RR Presentation Format . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Example Use-Case: IP Address Tracking in DOCSIS Networks . . . 8 5. Example Use-Case: IP Address Tracking in DOCSIS Networks . . . 7
7. DNS Protocol Considerations . . . . . . . . . . . . . . . . . 9 6. DNS Protocol Considerations . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . . 14 10.3. Informative References . . . . . . . . . . . . . . . . . . 12
A.1. RRType Parameter Allocation Template . . . . . . . . . . . 14 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . . 13
A.2. Change History . . . . . . . . . . . . . . . . . . . . . . 15 A.1. RRType Parameter Allocation Template . . . . . . . . . . . 13
A.2. Change History . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
This base specification defines many Resource Record (RR) Types, and This base specification defines many Resource Record Types (RRTypes),
subsequent specifications have defined others. Each defined RRType and subsequent specifications have defined others. Each defined
provides a means of encoding particular data in the DNS. RRType provides a means of encoding particular data in the DNS.
48-bit Extended Unique Identifiers (EUI-48) [EUI48] and 64-bit 48-bit Extended Unique Identifiers (EUI-48) [EUI48] and 64-bit
Extended Unique Identifiers (EUI-64) [EUI64] are address formats Extended Unique Identifiers (EUI-64) [EUI64] are address formats
specified by the IEEE for use in various layer-2 networks, e.g. specified by the IEEE for use in various layer-2 networks, e.g.
ethernet. Ethernet.
This document defines two new RR Types, EUI48 and EUI64 for encoding This document defines two new RRTypes, EUI48 and EUI64 for encoding
EUI-48 and EUI-64 addresses in the DNS. EUI-48 and EUI-64 addresses in the DNS.
There are potentially severe privacy implications resulting from the
indiscriminate publication of link-layer addresses in the DNS (see
Section 8). This document recommends that EUI-48 or EUI-64 addresses
SHOULD NOT be published in the public DNS. This document specifies
an interoperable encoding of these address types for use in private
DNS namespaces, where the privacy implications can be constrained and
mitigated.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document uses capitalised keywords such as MUST and MAY to
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this describe the requirements for using the registered RRTypes. The
document are to be interpreted as described in [RFC2119]. intended meaning of those keywords in this document are the same as
those described in [RFC2119]. Although these keywords are often used
to specify normative requirements in IETF Standards, their use in
this document does not imply that this document is a standard of any
kind.
3. The EUI48 Resource Record 3. The EUI48 Resource Record
The EUI48 RR is used to store a single EUI-48 address in the DNS. The EUI48 Resource Record (RR) is used to store a single EUI-48
address in the DNS.
The Type value for the EUI48 RRType is 108 (decimal). The Type value for the EUI48 RRType is 108 (decimal).
The EUI48 RR is class-independent. The EUI48 RR is class-independent.
The EUI48 RR has no special Time-to-Live (TTL) requirements. The EUI48 RR has no special Time-to-Live (TTL) requirements.
3.1. EUI48 RDATA Wire Format 3.1. EUI48 RDATA Wire Format
The RDATA for an EUI48 RR consists of a single, 6-octet EUI48-Address The RDATA for an EUI48 RR consists of a single, 6-octet EUI48-Address
skipping to change at page 6, line 5 skipping to change at page 5, line 35
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2. EUI48 RR Presentation Format 3.2. EUI48 RR Presentation Format
The Address field MUST be represented as six two-digit hexadecimal The Address field MUST be represented as six two-digit hexadecimal
numbers separated by hyphens. The hexadecimal digits "A" through "F" numbers separated by hyphens. The hexadecimal digits "A" through "F"
MAY be represented in either upper or lower case. MAY be represented in either upper or lower case.
3.3. Example
The following EUI48 RR stores the EUI-48 unicast address 00-00-5e-00-
53-2a.
host.example. 86400 IN EUI48 00-00-5e-00-53-2a
4. The EUI64 Resource Record 4. The EUI64 Resource Record
The EUI64 RR is used to store a single EUI-64 address in the DNS. The EUI64 RR is used to store a single EUI-64 address in the DNS.
The Type value for the EUI64 RR is 109 (decimal). The Type value for the EUI64 RR is 109 (decimal).
The EUI64 RR is class-independent. The EUI64 RR is class-independent.
The EUI64 RR has no special TTL requirements. The EUI64 RR has no special TTL requirements.
skipping to change at page 7, line 5 skipping to change at page 6, line 33
| EUI-64 Address | | EUI-64 Address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. EUI64 RR Presentation Format 4.2. EUI64 RR Presentation Format
The Address field MUST be represented as eight two-digit hexadecimal The Address field MUST be represented as eight two-digit hexadecimal
numbers separated by hyphens. The hexadecimal digits "A" through "F" numbers separated by hyphens. The hexadecimal digits "A" through "F"
MAY be represented in either upper or lower case. MAY be represented in either upper or lower case.
5. Examples 4.3. Example
The following EUI48 RR stores the EUI-48 unicast address 00-00-5e-00-
53-2a.
host.example. 86400 IN EUI48 00-00-5e-00-53-2a
The following EUI64 RR stores the EUI-64 address 00-00-5e-ef-10-00- The following EUI64 RR stores the EUI-64 address 00-00-5e-ef-10-00-
00-2a. 00-2a.
host.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a host.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a
6. Example Use-Case: IP Address Tracking in DOCSIS Networks 5. Example Use-Case: IP Address Tracking in DOCSIS Networks
Canadian cable Internet subscribers are assigned IP addresses using Canadian cable Internet subscribers are assigned IP addresses using
DHCP, using a DHCP server operated by a cable company. In the case DHCP, using a DHCP server operated by a cable company. In the case
where a cable company provides last-mile connectivity to a subscriber where a cable company provides last-mile connectivity to a subscriber
on behalf of a third party company (reseller), the DHCP server on behalf of a third party company (reseller), the DHCP server
assigns addresses from a pool supplied by the reseller. The reseller assigns addresses from a pool supplied by the reseller. The reseller
retains knowledge of the EUI-48 address of the DOCSIS modem supplied retains knowledge of the EUI-48 address of the DOCSIS modem supplied
to the subscriber, but has no direct knowledge of the IP addresses to the subscriber, but has no direct knowledge of the IP addresses
assigned. In order for the reseller to be able to map the IP address assigned. In order for the reseller to be able to map the IP address
assigned to a subscriber to that EUI-48 address (and hence to the assigned to a subscriber to that EUI-48 address (and hence to the
subscriber identity), the cable company can make available subscriber identity), the cable company can make available
information from the DHCP server which provides that (EUI-48, IP) information from the DHCP server which provides that (EUI-48, IP)
address mapping. address mapping.
Cable companies in Canada are required [NTRE038D] to make this Cable companies in Canada are required [NTRE038D] to make this
address mapping available using the DNS. Zones containing the address mapping available using the DNS. Zones containing the
relevant information are published on DNS servers, access to which is relevant information are published on DNS servers, access to which is
restricted to the resellers corresponding to particular sets of restricted to the resellers corresponding to particular sets of
subscribers. subscribers. Subscriber address information is not published in the
public DNS.
Existing DNS schemas for the representation of (EUI-48, IP) mapping Existing DNS schemas for the representation of (EUI-48, IP) mapping
used by Canadian cable companies are varied and inefficient; in the used by Canadian cable companies are varied and inefficient; in the
absence of a RRType for direct encoding of EUI-48 addresses, absence of a RRType for direct encoding of EUI-48 addresses,
addresses are variously encoded into owner names or are published in addresses are variously encoded into owner names or are published in
TXT records. TXT records.
The specification in this document facilitates a more efficient, The specification in this document facilitates a more efficient,
consistent and reliable representation of (EUI-48, IP) mapping than consistent and reliable representation of (EUI-48, IP) mapping than
was previously available. was previously available.
7. DNS Protocol Considerations 6. DNS Protocol Considerations
The specification of the new RRTYPEs in this document has no effect The specification of the new RRTypes in this document has no effect
on the address resolution behavior of any previously existing network on the address resolution behaviour of any previously existing
processes or protocols. Proposals or specifications to modify or network processes or protocols. Proposals or specifications to
augment address resolution processes or protocols by making use of modify or augment address resolution processes or protocols by making
these RRTPES should specify how any address conflicts or use of use of these RRTypes should specify how any address conflicts or use
multiple EUI48/EUI64 RRs are handled. of multiple EUI48/EUI64 RRs are handled.
8. IANA Considerations 7. IANA Considerations
IANA has assigned the RRType value 108 (decimal) for EUI48 and 109 IANA has assigned the RRType value 108 (decimal) for EUI48 and 109
(decimal) for EUI64. This document directs the IANA to confirm that (decimal) for EUI64. This document directs the IANA to confirm that
the corresponding entries in the "Resource Record (RR) TYPEs" the corresponding entries in the "Resource Record (RR) TYPEs" sub-
subregistry match the following data: registry match the following data:
+-------+-------+-------------------+---------------+ +-------+-------+-------------------+---------------+
| Type | Value | Meaning | Reference | | Type | Value | Meaning | Reference |
+-------+-------+-------------------+---------------+ +-------+-------+-------------------+---------------+
| EUI48 | 108 | an EUI-48 address | this document | | EUI48 | 108 | an EUI-48 address | this document |
| | | | | | | | | |
| EUI64 | 109 | an EUI-64 address | this document | | EUI64 | 109 | an EUI-64 address | this document |
+-------+-------+-------------------+---------------+ +-------+-------+-------------------+---------------+
9. Security Considerations 8. Security Considerations
There may be privacy concerns with publishing EUI addresses in the There are privacy concerns with the publication of link-layer
global DNS. EUI-48 and EUI-64 addresses with the Global bit zero addresses in the DNS. EUI-48 and EUI-64 addresses with the Local/
[RFC5342] are intended to represent unique identifiers for network Global bit zero [RFC5342] (referred to in [RFC4291] as the universal/
connected equipment notwithstanding many observed cases of local bit) are intended to represent unique identifiers for network
duplication due to manufacturing errors, unauthorized use of OUIs, connected equipment, notwithstanding many observed cases of
duplication due to manufacturing errors, unauthorised use of OUIs,
and address spoofing through configuration of network interfaces. and address spoofing through configuration of network interfaces.
Publication of EUI-48 or EUI-64 addresses in the global DNS may Publication of EUI-48 or EUI-64 addresses in the DNS may result in
result in privacy issues in the form of unique trackable identities. privacy issues in the form of unique trackable identities that in
some cases may be permanent.
IP addresses and DNS names for network devices typically change over For example, although IP addresses and DNS names for network devices
time but EUI-48 and EUI-64 addresses normally provide a unique typically change over time, EUI-48 and EUI-64 addresses configured on
identity for a network device. As an example of this, consider a the same devices are normally far more stable (in many cases,
wireless provider that publishes the EUI-48 addresses of its effectively invariant). Publication of EUI-48 addresses associated
subscribers in the global DNS under the same name as their IP host with user devices in a way that could be mapped to assigned IP
name. An entity that wants to relate web queries, for example, to a addresses would allow the behaviour of those users to be tracked by
specific customer might, if that customer is using a globally-unique third parties, regardless of where and how the user's device is
IP address, be able to do a reverse query from the IP address to a connected to the Internet. This might well result in a loss of
DNS name, and then a forward query for the EUI information. If privacy for the user.
possible, this would enable a tracking entity to relate queries to
specific identity regardless of changes in IP addresses and DNS names
resulting in a loss of privacy for the subscriber.
These potential concerns can be mitigated through restricting access The publication of EUI-48 or EUI-64 addresses associated with
to zones containing EUI48 or EUI64 RRs or storing such information deployed equipment, using the mechanism described in this document or
under a domain name whose construction requires that the querier any other mechanism, has the potential to facilitate MAC cloning --
already know some other permanent identifier. that is, facilitate link-layer attacks against deployed devices, e.g.
to disrupt service or intercept data.
10. Acknowledgements These concerns can be mitigated by restricting access to DNS zones
containing EUI48 or EUI64 RRs to specific, authorised clients and by
provisioning them in DNS zones that exist in private namespaces only.
This document recommends that EUI-48 or EUI-64 addresses SHOULD NOT
be published in the public DNS.
9. Acknowledgements
The author acknowledges the contributions of Olafur Gudmundsson, Mark The author acknowledges the contributions of Olafur Gudmundsson, Mark
Smith, Andrew Sullivan, Roy Arends, Michael StJohns and Donald Smith, Andrew Sullivan, Roy Arends, Michael StJohns, Donald Eastlake
Eastlake III. III, Randy Bush and John Klensin.
11. References 10. References
11.1. Normative References 10.1. Normative References
[EUI48] IEEE, "Guidelines for use of a 48-bit Extended Unique [EUI48] IEEE, "Guidelines for use of a 48-bit Extended Unique
Identifier (EUI-48)". Identifier (EUI-48)".
[EUI64] IEEE, "Guidelines for use of a 64-bit Extended Unique [EUI64] IEEE, "Guidelines for use of a 64-bit Extended Unique
Identifier (EUI-64)". Identifier (EUI-64)".
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage
for IEEE 802 Parameters", BCP 141, RFC 5342, for IEEE 802 Parameters", BCP 141, RFC 5342,
September 2008. September 2008.
11.2. Informative References 10.2. Informative References
[NTRE038D] [NTRE038D]
CRTC Interconnection Steering Committee Network Working CRTC Interconnection Steering Committee Network Working
Group, "Implementation of IP Address Tracking in DOCSIS Group, "Implementation of IP Address Tracking in DOCSIS
Networks (TIF18)". Networks (TIF18)", October 2006.
10.3. Informative References
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Appendix A. Editorial Notes Appendix A. Editorial Notes
This section (and sub-sections) to be removed prior to publication. This section (and sub-sections) to be removed prior to publication.
A.1. RRType Parameter Allocation Template A.1. RRType Parameter Allocation Template
DNS RRTYPE PARAMETER ALLOCATION TEMPLATE DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
A. Submission Date: 2013-03-18 A. Submission Date: 2013-03-18
skipping to change at page 16, line 5 skipping to change at page 14, line 41
hyphens). Examples changed to use to-be-assigned addresses under hyphens). Examples changed to use to-be-assigned addresses under
the IANA OUI. the IANA OUI.
03 Example EUI48 and EUI64 addresses changed to match the guidance in 03 Example EUI48 and EUI64 addresses changed to match the guidance in
draft-eastlake-5342bis-00. "EUI48" corrected to "EUI64" in the draft-eastlake-5342bis-00. "EUI48" corrected to "EUI64" in the
text of Section 4.1. Incorporated suggestions on DNS resolution text of Section 4.1. Incorporated suggestions on DNS resolution
and privacy considerations from Michael StJohns and Donald and privacy considerations from Michael StJohns and Donald
Eastlake III. Added example use case relating to Canadian DOCSIS Eastlake III. Added example use case relating to Canadian DOCSIS
networks. networks.
04 Incorporated suggestions from John Klensin. Intended status
changed to informational from standards track. Moved examples to
a more sensible place.
05 Add emphasis that the publication of link-layer addresses in the
DNS has potentially severe privacy implications, and is not
recommended by this document. Recommend that publication of link-
layer addresses in the public DNS should not happen at all.
Various wordsmithing for the purposes of clarity.
06 Add text regarding MAC cloning in the Security Considerations
section. Make text that mentions the "Global bit" more consistent
with [RFC5342] and [RFC4291].
07 Make the "SHOULD NOT publish in the public DNS" recommendation
stronger.
Author's Address Author's Address
Joe Abley Joe Abley
TekSavvy Solutions, Inc. TekSavvy Solutions, Inc.
470 Moore Street 470 Moore Street
London, ON N6C 2C2 London, ON N6C 2C2
Canada Canada
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: jabley@teksavvy.ca Email: jabley@teksavvy.ca
 End of changes. 33 change blocks. 
77 lines changed or deleted 131 lines changed or added

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