idnits 2.17.1 draft-ietf-dhc-relay-id-suboption-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 4, 2011) is 4709 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) == Missing Reference: 'TBA' is mentioned on line 218, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-dhc-dhcpv4-bulk-leasequery-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC B. Joshi 3 Internet-Draft R. Rao 4 Intended status: Standards Track Infosys Technologies Ltd. 5 Expires: December 6, 2011 M. Stapp 6 Cisco Systems, Inc. 7 June 4, 2011 9 The DHCPv4 Relay Agent Identifier Suboption 10 draft-ietf-dhc-relay-id-suboption-08.txt 12 Abstract 14 This draft defines a new Relay Agent Identifier suboption for the 15 Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information 16 option. The suboption carries a value that uniquely identifies the 17 relay agent device within the administrative domain. The value is 18 typically administratively-configured in the relay agent. The 19 suboption allows a DHCP relay agent to include the identifier in the 20 DHCP messages it sends. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 6, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Example Use-Cases . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Industrial Ethernet . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Bulk Leasequery . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Relay Identifier Types . . . . . . . . . . . . . . . . . . . . 4 63 6. Identifier Stability . . . . . . . . . . . . . . . . . . . . . 5 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) [RFC2131] 75 provides IP addresses and configuration information for IPv4 clients. 76 It includes a relay agent capability, in which network elements 77 receive broadcast messages from clients and forward them to DHCP 78 servers as unicast messages. In many network environments, relay 79 agents add information to the DHCP messages before forwarding them, 80 using the Relay Agent Information option [RFC3046]. Servers that 81 recognize the relay agent information option echo it back in their 82 replies. 84 This specification introduces a Relay Agent Identifier suboption for 85 the Relay Agent Information option. The Relay-Id suboption carries a 86 sequence of octets that is intended to uniquely identify the relay 87 agent within the administrative domain. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 DHCPv4 terminology is defined in [RFC2131], and the DHCPv4 Relay 96 Agent Information Option in [RFC3046]. 98 3. Example Use-Cases 100 3.1. Industrial Ethernet 102 DHCP typically identifies clients based on information in their DHCP 103 messages - such as the Client-Identifier option, or the value of the 104 chaddr field. In some networks, however, the location of a client - 105 its point of attachment to the network - is a more useful identifier. 106 In factory-floor networks (commonly called 'Industrial' networks), 107 for example, the role a device plays is often fixed and based on its 108 location. Using manual address configuration is possible (and is 109 common) but it would be beneficial if DHCP configuration could be 110 applied to these networks. 112 One way to provide connection-based identifiers for industrial 113 networks is to have the network elements acting as DHCP relay agents 114 supply information that a DHCP server could use as a client 115 identifier. A straightforward way to form identifier information is 116 to combine something that is unique within the scope of the network 117 element, such as a port/slot value, with something that uniquely 118 identifies that network element, such as a Relay Agent Identifier. 120 3.2. Bulk Leasequery 122 There has been quite a bit of recent interest in extending the DHCP 123 Leasequery protocol [RFC4388] to accommodate some additional 124 situations. There is a recent draft 125 ([I-D.ietf-dhc-dhcpv4-bulk-leasequery]) proposing a variety of 126 enhancements to the existing Leasequery protocol. The draft 127 describes a use-case where a relay agent queries DHCP servers using 128 the Relay Identifier to retrieve all the leases allocated through the 129 relay agent. 131 4. Suboption Format 133 Format of the Relay Agent Identifier suboption: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |SUBOPT_RELAY_ID| length | type | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 140 . . 141 . identifier (variable) . 142 . . 143 +---------------------------------------------------------------+ 145 Where: 147 SUBOPT_RELAY_ID [TBA] 149 length the number of octets in the suboption 150 (excluding the suboption ID and length fields); 151 the minimum length is two. 153 type a single octet describing the type of 154 identifier that is present. 156 identifier the identifying data. 158 5. Relay Identifier Types 160 For clarity, the suboption specified here includes a type octet that 161 describes the data used in the identifier field. The type value zero 162 is reserved and MUST NOT be used. One type value is defined here: 163 RELAY_IDENTIFIER_OPAQUE. RELAY_IDENTIFIER_OPAQUE is used when the 164 identifier field contains a series of octets. 166 6. Identifier Stability 168 If the relay identifier is to be meaningful it has to be stable. A 169 relay agent SHOULD use a single identifier type and value 170 consistently. The identifier used by a relay device SHOULD be 171 committed to stable storage, unless the relay device can regenerate 172 the value upon reboot. 174 Relay agents SHOULD make their relay identifiers visible to their 175 administrators via their user interface, through a log entry, or 176 through some other mechanism. Among other uses, this is expected to 177 be useful to administrators in detecting misconfiguration of relay 178 identifiers (for example, multiple relay agents configured with the 179 same relay identifier). 181 Implementors should note that the identifier needs to be present in 182 all DHCP message types where its value is being used by the DHCP 183 server. The relay agent may not be able to add the Relay Agent 184 Information option to all messages - such as RENEW messages sent as 185 IP unicasts. In some deployments that might mean that the server has 186 to be willing to continue to associate the relay identifier it has 187 last seen with a lease that is being RENEWed. Other deployments may 188 prefer to use the Server Identifier Override suboption [RFC5107] to 189 permit the relay device to insert the Relay Agent Information option 190 into all relayed messages. 192 Handling situations where a relay agent device is replaced is another 193 aspect of "stability". One of the use-cases for the relay identifier 194 is to permit a server to associate clients' lease bindings with the 195 relay device connected to the clients. If the relay device is 196 replaced, because it has failed or been upgraded, it may be desirable 197 for the new device to continue to provide the same relay identifier 198 as the old device. Implementors should be aware of this possibility, 199 and consider making it possible for administrators to configure the 200 identifier. 202 7. Security Considerations 204 Security issues with the Relay Agent Information option and its use 205 by servers in address assignment are discussed in [RFC3046] and 206 [RFC4030]. Relay agents who send the Relay Agent Identifier 207 suboption SHOULD use the Relay Agent Authentication suboption 209 [RFC4030] to provide integrity protection and to avoid duplication of 210 relay identifiers by malicious entities. 212 8. IANA Considerations 214 We request that IANA assign a new suboption code from the registry of 215 DHCP Agent Sub-Option Codes maintained in 216 http://www.iana.org/assignments/bootp-dhcp-parameters. 218 Relay Agent Identifier Suboption [TBA] 220 We request that IANA establish a new registry of DHCP Relay Agent 221 Identifier Sub-Option Types, to be maintained in 222 http://www.iana.org/assignments/bootp-dhcp-parameters. The 223 Identifier Type is a single octet. The initial values assigned in 224 this document are: 226 Reserved 0 227 RELAY_IDENTIFIER_OPAQUE 1 229 Additional Identifier Type values will be allocated and assigned 230 through IETF Review, as defined in [RFC5226]. 232 9. Acknowledgments 234 Thanks to Ted Lemon, David W. Hankins and Bernie Volz for providing 235 valuable suggestions. 237 10. References 239 10.1. Normative References 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, March 1997. 244 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 245 RFC 2131, March 1997. 247 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 248 RFC 3046, January 2001. 250 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 251 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 252 Option", RFC 4030, March 2005. 254 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 255 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 256 May 2008. 258 10.2. Informative References 260 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 261 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 263 [RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 264 "DHCP Server Identifier Override Suboption", RFC 5107, 265 February 2008. 267 [I-D.ietf-dhc-dhcpv4-bulk-leasequery] 268 Kinnear, K., Volz, B., Russell, N., Stapp, M., Rao, D., 269 Joshi, B., and P. Kurapati, "Bulk DHCPv4 Lease Query", 270 draft-ietf-dhc-dhcpv4-bulk-leasequery-04 (work in 271 progress), May 2011. 273 Authors' Addresses 275 Bharat Joshi 276 Infosys Technologies Ltd. 277 44 Electronics City, Hosur Road 278 Bangalore 560 100 279 India 281 Email: bharat_joshi@infosys.com 282 URI: http://www.infosys.com/ 284 D.T.V Ramakrishna Rao 285 Infosys Technologies Ltd. 286 44 Electronics City, Hosur Road 287 Bangalore 560 100 288 India 290 Email: ramakrishnadtv@infosys.com 291 URI: http://www.infosys.com/ 292 Mark Stapp 293 Cisco Systems, Inc. 294 1414 Massachusetts Ave. 295 Boxborough, MA 01719 296 USA 298 Phone: +1 978 936 0000 299 Email: mjs@cisco.com