idnits 2.17.1 draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In Relay chaining scenarios, any other relay agent other than first hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this option. -- The document date (March 12, 2012) is 4427 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Halwasia 3 Internet-Draft S. Bhandari 4 Intended status: Standards Track W. Dec 5 Expires: September 13, 2012 Cisco Systems 6 March 12, 2012 8 Client Link-layer Address Option in DHCPv6 9 draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01 11 Abstract 13 This document specifies the format and mechanism that is to be used 14 for encoding client link-layer address in DHCPv6 messages by defining 15 a new DHCPv6 Client Link-layer Address option. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 13, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Background and Scenario . . . . . . . . . . . . . . . . 3 59 3. DHCPv6 Client Link-layer Address Option . . . . . . . . . . . . 4 60 4. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 4 61 5. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . . 4 62 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 66 10. Change History (to be removed prior to publication as an 67 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 11. Normative References . . . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 This specification defines an optional mechanism and the related 74 DHCPv6 option to allow DHCPv6 client or first hop DHCPv6 relay agent 75 directly connected to the client to populate client link-layer 76 address in the DHCPv6 messages being sent towards the server. 78 2. Problem Background and Scenario 80 DHCPv4 protocol specification [RFC2131] provides a way to specify the 81 client hardware address in the DHCPv4 message header. DHCPv4 message 82 header has 'htype' and 'chaddr' fields to specify client hardware 83 address type and hardware address respectively. The client hardware 84 address thus learnt can be used by DHCPv4 server and relay in 85 different ways. In some of the deployments DHCPv4 servers use 86 'chaddr' as a customer identifier and a key for lookup in the client 87 lease database. 89 With the incremental deployment of IPv6 to existing IPv4 networks, 90 effectievly an enablement of dual-stack, there will be devices that 91 act as both DHCPv4 and DHCPv6 clients. In service provider 92 deployments, a typical DHCPv4 implemention will use the client 93 hardware address as one of the keys to build DHCP client lease 94 database. In dual stack scenarios it is desirable for the operator 95 to associate DHCPv4 and DHCPv6 messages as belonging to the same 96 client interface based on an identifier that is already used by that 97 operator such as the client hardware address. 99 Currently, the DHCPv6 protocol specification [RFC3315] does not 100 define a way for DHCP clients to specify client link-layer address in 101 the DHCPv6 message sent towards DHCPv6 Server. Similarly DHCPv6 102 Relay or Server cannot glean client link-layer address from the 103 contents of DHCPv6 message received. DHCPv6 protocol specification 104 mandates all clients to prepare and send DUID as the client 105 identifier option in all the DHCPv6 message exchange. However none 106 of these methods provide a simple way to extract client's link-layer 107 address.This presents a problem to an operator who is using an 108 existing DHCPv4 system with the client hardware address as the 109 customer identifier, and desires to correlate DHCPv6 assignments 110 using the same identifier. Modifying the system to use DUID based 111 correlation across DHCPv4 and DHCPv6 is possible, but it requires a 112 modification of the DHCPv4 system and associated back-ends. 114 Providing an option in DHCPv6 messages to carry client link-layer 115 address explicitly will help above mentioned scenarios. For e.g. it 116 can be used along with other identifiers to associate DHCPv4 and 117 DHCPv6 messages from a dual stack client. Further, having client 118 link-layer address in DHCPv6 will help in proving additional 119 information in event debugging and logging related to the client at 120 relay and server. The proposed option may be used in wide range of 121 networks, two notable deployment models are service provider and 122 enterprise network environments. 124 3. DHCPv6 Client Link-layer Address Option 126 The format of the DHCPv6 Client Link-layer Address option is shown 127 below. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | OPTION_CLIENT_LINKLAYER_ADDR | option-length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | hardware type (16 bits) | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 135 | link-layer address (variable length) | 136 | | 137 | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 option-code: OPTION_CLIENT_LINKLAYER_ADDR (TBD) 141 option-length: 2 + length of link-layer address 142 hardware type: Client Link-layer address type. The hardware type MUST be a 143 valid hardware type assigned by the IANA, as described in [RFC0826] 144 link-layer address: Client Link-layer address. 146 4. DHCPv6 Client Behavior 148 All hosts or clients MAY include DHCPv6 Client link-layer address 149 option in all the upstream DHCPv6 messages. 151 5. DHCPv6 Relay Agent Behavior 153 DHCPv6 Relay agents which are directly connected to clients/hosts MAY 154 look for Client Link-layer Address option in the incoming DHCPv6 155 client message. Irrespective of the presence of client link-layer 156 option in incomming DHCPv6 client messages, DHCPv6 Relay agents MAY 157 include client link-layer address option in relayed DHCPv6 (RELAY- 158 FORW) message. The DHCPv6 Relay agent behaviour can depend on 159 configuration that decides whether Client Link-layer Address option 160 needs to be processed and included. 162 In Relay chaining scenarios, any other relay agent other than first 163 hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this 164 option. 166 6. DHCPv6 Server Behavior 168 If DHCPv6 Server is configured to store or use client link-layer 169 address, it SHOULD first look for the client link-layer address 170 option in the RELAY-FORW DHCP message of the DHCPv6 Relay agent 171 closest to the client. In case it is not found, Server SHOULD look 172 for client link-layer address option in the client DHCP message. 173 Further, this behavior w.r.t the precedence of DHCPv6 server to look 174 for Client link-layer address option can be overridden based upon the 175 local policies. 177 There is no requirement that a server return this option and its data 178 in a downstream DHCP message. 180 7. IANA Considerations 182 IANA is requested to assign an option code to 183 OPTION_CLIENT_LINKLAYER_ADDR from the "DHCPv6 and DHCPv6 options" 184 registry (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- 185 parameters.xml). 187 8. Security Considerations 189 Security issues related DHCPv6 are described in section 23 of 190 [RFC3315]. 192 9. Acknowledgements 194 Many thanks to Bernie Volz, Hemant Singh, Simon Hobson, Tina TSOU, 195 Andre Kostur, Chuck Anderson, Steinar Haug, Niall O'Reilly, Jarrod 196 Johnson and Vincent Zimmer for their input and review. 198 10. Change History (to be removed prior to publication as an RFC) 200 Changes from -00 to -01 202 a. "hardware address" has been renamed to "Link-layer address" to be 203 consistent with DHCPv6 terminology 205 b. 1 byte chtype in DHCPv6 Client Link-layer Address option is 206 replaced with 2 byte hardware type 208 c. chaddr in DHCPv6 Client Link-layer Address option is renamed as 209 link-layer address 211 11. Normative References 213 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 214 converting network protocol addresses to 48.bit Ethernet 215 address for transmission on Ethernet hardware", STD 37, 216 RFC 826, November 1982. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 222 RFC 2131, March 1997. 224 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 225 and M. Carney, "Dynamic Host Configuration Protocol for 226 IPv6 (DHCPv6)", RFC 3315, July 2003. 228 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 229 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 230 May 2011. 232 Authors' Addresses 234 Gaurav Halwasia 235 Cisco Systems 236 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 237 Bangalore, KARNATAKA 560 087 238 India 240 Phone: +91 80 4426 1321 241 Email: ghalwasi@cisco.com 242 Shwetha Bhandari 243 Cisco Systems 244 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 245 Bangalore, KARNATAKA 560 087 246 India 248 Phone: +91 80 4426 0474 249 Email: shwethab@cisco.com 251 Wojciech Dec 252 Cisco Systems 253 Haarlerbergweg 13-19 254 1101 CH Amsterdam, Amsterdam 560 087 255 The Netherlands 257 Email: wdec@cisco.com