idnits 2.17.1 draft-ietf-dhc-vpn-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2434], [RFC2131], [RFC2685]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: Servers that do not understand this option will allocate an address using their normal algorithms and will not return this option in the DHCPOFFER or DHCPACK. In this case the client will discard the DHCPOFFER or DHCPACK. Servers that understand this option but are administratively configured to ignore the option MUST ignore the option, use their normal algorithms to allocate an address, and MUST NOT return this option in the DHCPOFFER or DHCPACK. In this case the client will discard the DHCPOFFER or DHCPACK. In other words, this option MUST not appear in a DHCPOFFER from a server unless it was used by the server in making the address allocation requested. -- 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 (July 2001) is 8318 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: 'RFC 2685' is mentioned on line 102, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 179, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC2119' is defined on line 196, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 202, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Request for Comments: DRAFT Richard Johnson 3 Kim Kinnear 4 Mark Stapp 5 Jay Kumarasamy 6 Cisco Systems, Inc. 8 July 2001 9 Expires January 2001 11 DHCP VPN Information option 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 To learn the current status of any Internet-Draft, please check the 36 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 37 Directories on ds.internic.net (US East Coast), nic.nordu.net 38 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 39 Rim). 41 Copyright Notice 43 Copyright (C) The Internet Society (2000). All Rights Reserved. 45 Abstract 47 This memo defines a new DHCP option for passing VPN information 48 between the DHCP client and the DHCP server. It is intended for use 49 primarily by DHCP proxy clients in situations where VPN information 50 needs to be passed to the DHCP server for proper address allocation 51 to take place. 53 Introduction 55 There is a growing use of Virtual Private Network (VPN) 56 configurations. The growth comes from many areas; individual client 57 systems needing to appear to be on the home corporate network even 58 when traveling, ISPs providing extranet connectivity for customer 59 companies, etc. In some of these cases there is a need for the DHCP 60 client to communicate to the DHCP server the VPN from which an 61 address, and other resources, should be allocated. Currently there 62 is no way to pass this information. 64 This option would most likely not be used by an actual DHCP end-user 65 client such as a workstation or laptop. It is primarily intended to 66 be used by a DHCP proxy client which would be using DHCP in order to 67 allocate an IP address on behalf of some other protocol or client. 69 This memo defines a new DHCP option, the VPN Information option, 70 which allows the DHCP client to specify the VPN Information needed in 71 order to allocate an address. If the receiving DHCP server 72 understands the VPN Information option, this information may be used 73 in conjunction with other information in determining the subnet on 74 which to select an address as well as other information such as DNS 75 server, default router, etc. 77 VPN Information Option Definition 79 The VPN Information option is a DHCP option. The option contains 80 generalized VPN information in one of two formats: NVT ASCII VPN 81 identifier, or RFC2685 VPN-ID. 83 The format of the option is: 85 Code Len Type VPN Information octets 86 +-----+-----+------+-----+-----+-----+--- 87 | TBD | n | t | v1 | v2 | v3 | ... 88 +-----+-----+------+-----+-----+-----+--- 90 Type: 0 NVT ASCII VPN identifier 91 1 RFC2685 VPN-ID 92 2-255 Not Allowed 94 The option minimum length (n) is 2. 96 There are two types of identifiers which can be placed in the VPN 97 Information Suboption. The first type of identifier which can be 98 placed in the VPN Information Suboption is an NVT ASCII string. It 99 MUST NOT be terminated with a zero byte. 101 The second type of identifier which can be placed in the VPN 102 Information Suboption is an RFC2685 VPN-ID [RFC 2685], which is 103 typically 14 hex digits in length (though it can be any length as far 104 as the VPN Information Suboption is concerned). 106 If the type field is set to zero (0), it indicates that all following 107 bytes of the option contain a NVT ASCII string. This string MUST NOT 108 be terminated with a zero byte. 110 If the type field is set to one (1), it indicates that all following 111 bytes should be interpreted in agreement with [RFC2685] as a VPN 112 Identifier, typically 14 hex digits. 114 All other values of the type field are invalid as of this memo and 115 VPN options containing any other value than zero (0) or one (1) 116 SHOULD be ignored. 118 Any VPN information contained in a DHCP Relay suboption SHOULD 119 override the information contained in this VPN Information option. 121 Servers configured to support this option MUST return an identical 122 copy of the option to any client that sends it, regardless of whether 123 or not the client requests the option in a parameter request list. 124 Clients using this option MUST discard DHCPOFFER or DHCPACK packets 125 that do not contain this option. 127 This option provides the DHCP server additional information upon 128 which to make a determination of address to be assigned. The DHCP 129 server, if it is configure to support this option, should use this 130 information in addition to other options included in the DHCPDISCOVER 131 packet in order to assign an IP address for DHCP client. 133 In the event that a VPN Informmation Option and a VPN Information 134 Relay Suboption are both received in a particular DHCP client packet, 135 the information from the VPN Information Suboption MUST be used in 136 preference to the information in the VPN Information Option. 138 Servers that do not understand this option will allocate an address 139 using their normal algorithms and will not return this option in the 140 DHCPOFFER or DHCPACK. In this case the client will discard the 141 DHCPOFFER or DHCPACK. Servers that understand this option but are 142 administratively configured to ignore the option MUST ignore the 143 option, use their normal algorithms to allocate an address, and MUST 144 NOT return this option in the DHCPOFFER or DHCPACK. In this case the 145 client will discard the DHCPOFFER or DHCPACK. In other words, this 146 option MUST not appear in a DHCPOFFER from a server unless it was 147 used by the server in making the address allocation requested. 149 Security Considerations 151 DHCP currently provides no authentication or security mechanisms. 152 Potential exposures to attack are discussed is section 7 of the 153 protocol specification [RFC2131]. 155 The VPN Information option could be used by a client in order to 156 obtain an IP address from a VPN other than the one where it should. 157 DHCP relays MAY choose to remove the option before passing on 158 DHCPDISCOVER packets. Another possible defense would be for the DHCP 159 relay to insert a Relay option containing a VPN Information 160 Suboption, which would override the DHCP VPN Information option. 162 This option would allow a client to perform a more complete address- 163 pool exhaustion attack since the client would no longer be restricted 164 to attacking address-pools on just its local subnet. 166 Servers that implement the VPN Information option MUST by default 167 disable use of the feature; it must specifically be enabled through 168 configuration. Moreover, a server SHOULD provide the ability to 169 selectively enable use of the feature under restricted conditions, 170 e.g., by enabling use of the option only from explicitly configured 171 client-ids, enabling its use only by clients on a particular subnet, 172 or restricting the VPNs from which addresses may be requested. 174 IANA Considerations 176 IANA has assigned a value of TBD for the DHCP option code described 177 in this document. No assignment of values for the type field need be 178 made at this time. New values may only be defined by IETF Consensus, 179 as described in [RFC 2434]. Basically, this means that they are 180 defined by RFCs approved by the IESG. 182 Moreover, any changes or additions to the type byte codes MUST be 183 made concurrently in the type byte codes of the VPN Information 184 Option. The type bytes and data formats of the VPN Information 185 Option and VPN Information Suboption MUST always be identical. 187 Acknowledgements 189 This document is the result of work done within Cisco Systems. 190 Thanks to Kim Kinnear, Mark Stapp, and Jay Kumarasamy for their work 191 on this option definition and the other related work for which this 192 is necessary. 194 References 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", RFC 2119, BCP 14, March 1997. 199 [RFC2131] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 200 March 1997. 202 [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 203 Extensions", RFC 2132, March 1997. 205 [RFC2685] Fox, B. and Gleeson, B., "Virtual Private Networks 206 Identifier", RFC 2685, September 1999 208 Author Information: 210 Richard Johnson 211 Jay Kumarasamy 212 Cisco Systems 213 170 W. Tasman Dr. 214 San Jose, CA 95134 216 Phone: (408) 526-4000 218 EMail: jayk@cisco.com 219 raj@cisco.com 221 Kim Kinnear 222 Mark Stapp 223 Cisco Systems 224 250 Apollo Drive 225 Chelmsford, MA 01824 227 Phone: (978) 244-8000 229 EMail: kkinnear@cisco.com 230 mjs@cisco.com