idnits 2.17.1 draft-asati-dhc-relay-agent-config-00.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 date (September 29, 2010) is 4957 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: 'RFC2132' is mentioned on line 121, but not defined == Unused Reference: 'RFC2544' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'RFC5695' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 269, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2544 ** Downref: Normative reference to an Informational RFC: RFC 5695 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Rajiv Asati 2 Internet Draft Cisco Systems 3 Intended status: Standards Track 4 Expires: March 2011 Ralph Droms 5 Cisco Systems 7 September 29, 2010 9 DHCP Relay Agent Configuration Option 10 draft-asati-dhc-relay-agent-config-00.txt 12 Abstract 14 This document defines a Dynamic Host Configuration Protocol (DHCP) 15 Relay Agent Configuration option and associated machinery to 16 configure the Relay Agent. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on March 29, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction...................................................4 59 2. Key Words to Reflect Requirements..............................4 60 3. Problem / Requirement..........................................5 61 4. Relay Agent Configuration Option...............................5 62 5. Operation......................................................6 63 5.1. DHCP Relay Agent Procedures...............................6 64 5.1.1. DHCP Relay Agent Chaining............................7 65 5.2. DHCP Server Procedures....................................7 66 5.3. DHCP Client Procedures....................................7 67 6. Security Considerations........................................8 68 7. IANA Considerations............................................8 69 8. Acknowledgments................................................8 70 9. References.....................................................9 71 9.1. Normative References......................................9 72 9.2. Informative References....................................9 73 APPENDIX A: Applicability........................................10 74 A.1. Applicability to MPLS IP/VPN.............................10 75 Authors' Addresses...............................................12 77 1. Introduction 79 There are scenarios in which a network operator (Service Provider or 80 Enterprise) may desire the relay agent to be dynamically provisioned 81 while facilitating the server-client communication to ultimately 82 facilitate the service activation in a zero-touch manner. 84 One example is the provisioning of the Provider Edge (PE) router, 85 acting as the relay agent for the Customer Edge (CE) router, 86 acting as the (DHCP) client, during IP/VPN [RFC4364] service 87 activation. 89 DHCP [RFC2131][ RFC3315] is the predominant signaling protocol to 90 dynamically assign IP addresses and other TCP/IP configuration 91 parameters to routers and hosts. DHCP Relay Agent functionality 92 [RFC3046] is specified to facilitate the forwarding of DHCP messages 93 between the client and server through the relay agent. 95 DHCP server may use one or more sub-options within the "Relay Agent 96 Information" option [RFC3046] appended by Relay Agent, for IP 97 address and other parameter assignment policies to the Client. The 98 "Relay Agent Information" option [RFC3046] is limited to providing 99 the additional information from Relay Agent to the DHCP server to 100 aid the server. 102 This document proposes a new DHCP option (and sub-options) that the 103 Relay Agent can use to request and receive the desired Relay Agent 104 configuration information and that the DHCP server can use to 105 deliver the requested configuration information. The document also 106 describes the associated procedures and operations for the Relay 107 Agent and Server to achieve the auto-provisioning of VPN information 108 at the PE router acting as the relay agent. 110 2. Key Words to Reflect Requirements 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in BCP 14, RFC 2119 115 [RFC2119]. RFC 2119 defines the use of these key words to help make 116 the intent of standards track documents as clear as possible. While 117 this document uses these keywords, this document is not a standards 118 track document. 120 Additionally, this document freely uses the terms that are defined 121 in [RFC2131][RFC2132][RFC3046]. 123 3. Problem / Requirement 125 There are other methods to activate the VPN service by auto- 126 provisioning the CE router after it establishes the layer2 127 connectivity. However, this assumes and requires the adjacent PE 128 router to be provisioned in advance to ensure that the CE gets the 129 IP reachability through the PE router, and is able to participate in 130 the any-to-any VPN such as BGP IP/VPN [RFC4364]. This is one of the 131 key challenges that serve as one of the requirements for the 132 solution prescribed in this document. Another requirement is to make 133 use of the existing signaling protocol(s) and not impose multiple 134 protocols to achieve this. 136 4. Relay Agent Configuration Option 138 This document defines a new DHCP Option called the Relay Agent 139 Configuration Option. It is a "container" option for specific sub- 140 options. The format of the Relay Agent Configuration option is: 142 Code Len Agent Configuration Field 143 +------+------+------+------+------+------+--...-+------+ 144 | TBD | N | c1 | c2 | c3 | c4 | | cN | 145 +------+------+------+------+------+------+--...-+------+ 147 Figure 1 Relay Agent Configuration Option 149 Code = DHCP Option for Relay Agent Configuration (to be allocated 150 by IANA) 152 Len = Total number of octets (N) in the Agent Configuration Field 153 (inclusive of all sub-options) 155 Agent Configuration Field = One or more Sub-options, each encoded 156 as a SubOpt/Length/Value tuple, as shown below: 158 SubOpt Len Sub-option Value 159 +------+------+------------------------------...--------+ 160 | 1 | N' | | 161 +------+------+------------------------------...--------+ 163 Figure 2 Relay Agent Configuration Sub-Option 165 SubOpt = DHCP Sub-Option for Relay Agent Configuration 166 (to be allocated by IANA) 168 Len = Total number of octets (N') in a Sub-option 170 Sub-option Value = zero or more octets to encode the value. 172 The sub-options need not appear in any particular order. 174 5. Operation 176 5.1. DHCP Relay Agent Procedures 178 The relay agent adds the DHCP relay agent configuration option (& 179 needed sub-options) in the relayed message to request the relay 180 agent side configuration information from the server. 182 The addition of this option SHOULD be configurable, and SHOULD be 183 disabled by default. Relay agents SHOULD have separate 184 configurables for each sub-option to control whether it is added to 185 client-to-server packets. 187 A relay agent adding a Relay Agent Configuration Information Option 188 MUST add it as the last option (but before 'End Option' 255, if 189 present) or the second last option, if option 82 is present, in the 190 DHCP options field of any recognized BOOTP or DHCP packet forwarded 191 from a client to a server. 193 If the configuration information, provided by the DHCP server in its 194 response, is already present at the relay agent, then relay agent 195 SHOULD compare the existing configuration with the new one, and in 196 case of a mismatch, logs an error/event. 198 The relay agent MUST remove the relay agent configuration option 199 from the DHCP response and forward the remaining response to the 200 client. 202 The operation of relay agent for specific sub-options should be 203 specified with that sub-option. 205 5.1.1. DHCP Relay Agent Chaining 207 Relay agents receiving a DHCP packet from an untrusted circuit with 208 giaddr set to zero (indicating that they are the first-hop router) 209 but with a Relay Agent Configuration option already present in the 210 packet SHALL discard the packet and increment an error count. 212 A trusted circuit may contain a trusted downstream (closer to 213 client) network element (bridge) between the relay agent and the 214 client that MAY add a relay agent option but not set the giaddr 215 field. In this case, the relay agent does NOT add a "second" relay 216 agent option, but forwards the DHCP packet per normal DHCP relay 217 agent operations, setting the giaddr field as it deems appropriate. 219 The mechanisms for distinguishing between "trusted" and "untrusted" 220 circuits are specific to the type of circuit termination equipment, 221 and may involve local administration. 223 5.2. DHCP Server Procedures 225 The DHCP server examines the DHCP options in the incoming request, 226 and constructs the response. The DHCP server may poll any other 227 servers present in the OSS/BSS to construct the requested 228 configuration information, and ultimately include it in the relay 229 agent configuration option/sub-options of DHCP response. 231 5.3. DHCP Client Procedures 233 This document doesn't specify any changes to the client functioning. 235 The new option defined in this document is never passed to the 236 client. 238 6. Security Considerations 240 There are no specific security considerations within the scope of 241 this document. 243 7. IANA Considerations 245 TBD. 247 8. Acknowledgments 249 Thanks to Shwetha Bhandari for providing feedback. 251 This document was prepared using 2-Word-v2.0.template.dot. 253 9. References 255 9.1. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 261 Network Interconnect Devices", RFC 2544, March 1999. 263 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 264 2131, March 1997. 266 [RFC5695] Droms, R. and Alexanderand S., "DHCP Options and BOOTP 267 Vendor Extensions", RFC 5695, March 1997. 269 [RFC3315] Droms, et. al., "Dynamic Host Configuration Protocol for 270 IPv6 (DHCPv6)", RFC 3315, July 2003. 272 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 273 3046, January 2001. 275 9.2. Informative References 277 [RFC4364] Rosen, E. and Rekther, Y., "BGP/MPLS IP Virtual Private 278 Networks (VPNs)", RFC 4364, February 2006. 280 APPENDIX A: Applicability 282 A.1. Applicability to MPLS IP/VPN 284 Figure 3 below illustrates a sample MPLS/VPN network topology in 285 which CE1, CE2 and CE3 are part of the same Virtual Private Network 286 (VPN), which is represented by VRF VPN1, say, in the MPLS/VPN 287 network. 289 CE1-------PE1-------MPLS/VPN Network-------PE2-----CE2 290 | \--------PE3-----CE3 291 | 292 PE10 293 | 294 Network/Service Management Complex 295 (DHCP Server, DNS Server, TFTP Server, etc.) 297 Figure 3 A Sample Network Topology 299 The "Network/Service Management Complex" is where the DHCP Server, 300 DNS server, TFTP server etc. may reside. 302 The PE router is assumed to have the DHCP relay agent functionality 303 as suggested in this document. The relay agent functionality may be 304 included globally for all PE-CE interfaces or selectively on 305 individual PE-CE interfaces. 307 Optionally, the unused PE-CE interfaces at the PE router may be 308 assigned to a default VRF prior to the successful DHCP processing 309 and auto-configuration. This helps to avoid having the CE get the 310 global reachability by accident prior to the DHCP operation 311 completion. 313 Assuming that the PE-CE interface is ready for the layer1/layer2 314 connectivity, CE would (be programmed to) broadcast the DHCP request 315 when the layer2 connectivity is established on either all or 316 designated port(s). 318 . This ensures that the DHCP request reaches the PE router. 319 . The DHCP request may include CE's unique identifier (such as 320 MAC address or S/N or Unique Device Identifier (UDI) etc.) that 321 is already known to the Servers in the Network/Service 322 Management Complex. 324 PE router upon receiving the DHCP request on a layer2 interface that 325 isn't configured with any IP address, relays it to the DHCP server 326 that may be pre-provisioned. 328 PE adds the DHCP relay agent configuration option (& needed sub- 329 options) in the relayed message to request the PE side configuration 330 information. 332 The DHCP server examines the DHCP options in the incoming request, 333 and constructs the response. The DHCP server may poll any other 334 servers present in the OSS/BSS for the PE configuration information, 335 so as to include it in the options/sub-options of DHCP response. 337 The PE configuration information, in RFC4364 environment, may 338 contain one or more of the following - 339 - IP address and subnet for PE-CE interface 340 - VRF Configuration (RD, RT etc.) 341 - Other PE-CE Interface configuration (description, vrf mapping 342 etc.) 343 - Selected Routing Protocol instance (for the CE) 344 - Neighbor and ASN information in case of BGP or EIGRP 345 - Security, QoS information etc. (for the CE) 347 If the VRF configuration, provided by the DHCP server in its 348 response, is already present at the PE router, then PE router must 349 compare the existing config with the new one, and logs an 350 error/event that could be sent to the DHCP server or to the OSS/BSS 351 or both, in case of a mismatch. 353 PE should accept the new config. The error/event log will help to 354 get the operator attention for further validation. New DHCP sub- 355 option is defined for this purpose. 357 The PE router removes the PE specific information (the new DHCP 358 relay agent configuration option) from the DHCP response and forward 359 the remaining response to the CE router, which will process it as 360 usual (not impacted by this document). 362 Authors' Addresses 364 Rajiv Asati 365 Cisco Systems, 366 7025 Kit Creek Rd, RTP, NC, 27709 367 Email: rajiva@cisco.com 369 Ralph Droms 370 Cisco Systems, 371 200 Beaver Brook Road, Boxborough, MA, 01719 372 Email: rdroms@cisco.com