idnits 2.17.1 draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03.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 -- The document date (October 18, 2012) is 4207 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 (~~), 1 warning (==), 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: April 21, 2013 Cisco Systems 6 October 18, 2012 8 Client Link-layer Address Option in DHCPv6 9 draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 11 Abstract 13 This document specifies the format and mechanism that is to be used 14 for encoding client link-layer address in DHCPv6 relay forward 15 messages by defining 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 April 21, 2013. 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 Relay Agent Behavior . . . . . . . . . . . . . . . . . . 4 61 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This specification defines an optional mechanism and the related 71 DHCPv6 option to allow first hop DHCPv6 relay agent directly 72 connected to the client to populate client link-layer address in the 73 DHCPv6 messages being sent towards the server. 75 2. Problem Background and Scenario 77 DHCPv4 protocol specification [RFC2131] provides a way to specify the 78 client hardware address in the DHCPv4 message header. DHCPv4 message 79 header has 'htype' and 'chaddr' fields to specify client hardware 80 address type and hardware address respectively. The client hardware 81 address thus learnt can be used by DHCPv4 server and relay in 82 different ways. In some of the deployments DHCPv4 servers use 83 'chaddr' as a customer identifier and a key for lookup in the client 84 lease database. 86 With the incremental deployment of IPv6 to existing IPv4 networks, 87 effectively an enablement of dual-stack, there will be devices that 88 act as both DHCPv4 and DHCPv6 clients. In service provider 89 deployments, a typical DHCPv4 implementation will use the client 90 hardware address as one of the keys to build DHCP client lease 91 database. In dual stack scenarios it is desirable for the operator 92 to associate DHCPv4 and DHCPv6 messages as belonging to the same 93 client interface based on an identifier that is already used by that 94 operator such as the client hardware address. 96 Currently, the DHCPv6 protocol specification [RFC3315] does not 97 define a way for DHCP clients to specify client link-layer address in 98 the DHCPv6 message sent towards DHCPv6 Server. Similarly DHCPv6 99 Relay or Server cannot glean client link-layer address from the 100 contents of DHCPv6 message received. DHCPv6 protocol specification 101 mandates all clients to prepare and send DUID as the client 102 identifier option in all the DHCPv6 message exchange. However none 103 of these methods provide a simple way to extract client's link-layer 104 address. This presents a problem to an operator who is using an 105 existing DHCPv4 system with the client hardware address as the 106 customer identifier, and desires to correlate DHCPv6 assignments 107 using the same identifier. Modifying the system to use DUID based 108 correlation across DHCPv4 and DHCPv6 is possible, but it requires a 109 modification of the DHCPv4 system and associated back-ends. 111 Providing an option in DHCPv6 relay forward messages to carry client 112 link-layer address explicitly will help above mentioned scenarios. 113 For e.g. it can be used along with other identifiers to associate 114 DHCPv4 and DHCPv6 messages from a dual stack client. Further, having 115 client link-layer address in DHCPv6 will help in proving additional 116 information in event debugging and logging related to the client at 117 relay and server. The proposed option may be used in wide range of 118 networks, two notable deployment models are service provider and 119 enterprise network environments. 121 3. DHCPv6 Client Link-layer Address Option 123 The format of the DHCPv6 Client Link-layer Address option is shown 124 below. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | OPTION_CLIENT_LINKLAYER_ADDR | option-length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | hardware type (16 bits) | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 132 | link-layer address (variable length) | 133 | | 134 | | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 option-code: OPTION_CLIENT_LINKLAYER_ADDR (TBD) 138 option-length: 2 + length of link-layer address 139 hardware type: Client Link-layer address type. The hardware type MUST be a 140 valid hardware type assigned by the IANA, as described in [RFC0826] 141 link-layer address: Client Link-layer address. 143 4. DHCPv6 Relay Agent Behavior 145 DHCPv6 Relay agents which receive messages originating from clients 146 (for example Solicit and Request, but not, for example, Relay Forward 147 or Advertise) MAY include the link-layer source address of the 148 received DHCPv6 message in Client Link-layer Address option in 149 relayed DHCPv6 Relay Forward messages. The DHCPv6 Relay agent 150 behavior can depend on configuration that decides whether Client 151 Link-layer Address option needs to be processed and included. 153 5. DHCPv6 Server Behavior 155 If DHCPv6 Server is configured to store or use client link-layer 156 address, it SHOULD look for the client link-layer address option in 157 the RELAY-FORW DHCP message of the DHCPv6 Relay agent closest to the 158 client. This specification does not specify the mechanism for DHCPv6 159 Server to find out link-layer address of the directly connected 160 clients as a DHCP option as it can obtain it directly from the link- 161 layer source address of the received DHCPv6 message. 163 There is no requirement that a server return this option and its data 164 in a downstream DHCP message. 166 6. IANA Considerations 168 IANA is requested to assign an option code to 169 OPTION_CLIENT_LINKLAYER_ADDR from the "DHCPv6 and DHCPv6 options" 170 registry (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- 171 parameters.xml). 173 7. Security Considerations 175 Security issues related DHCPv6 are described in section 23 of 176 [RFC3315]. 178 8. Acknowledgements 180 Many thanks to Ted Lemon, Bernie Volz, Hemant Singh, Simon Hobson, 181 Tina TSOU, Andre Kostur, Chuck Anderson, Steinar Haug, Niall 182 O'Reilly, Jarrod Johnson, Tomek Mrugalski and Vincent Zimmer for 183 their input and review. 185 9. Normative References 187 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 188 converting network protocol addresses to 48.bit Ethernet 189 address for transmission on Ethernet hardware", STD 37, 190 RFC 826, November 1982. 192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, March 1997. 195 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 196 RFC 2131, March 1997. 198 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 199 and M. Carney, "Dynamic Host Configuration Protocol for 200 IPv6 (DHCPv6)", RFC 3315, July 2003. 202 Authors' Addresses 204 Gaurav Halwasia 205 Cisco Systems 206 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 207 Bangalore, KARNATAKA 560 087 208 India 210 Phone: +91 80 4426 1321 211 Email: ghalwasi@cisco.com 213 Shwetha Bhandari 214 Cisco Systems 215 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 216 Bangalore, KARNATAKA 560 087 217 India 219 Phone: +91 80 4426 0474 220 Email: shwethab@cisco.com 222 Wojciech Dec 223 Cisco Systems 224 Haarlerbergweg 13-19 225 1101 CH Amsterdam, Amsterdam 560 087 226 The Netherlands 228 Email: wdec@cisco.com