idnits 2.17.1 draft-ietf-dhc-subsel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 36 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. ** The abstract seems to contain references ([3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 54: '...on 4.2, a server MAY, for administrati...' RFC 2119 keyword, line 86: '...a relay agent it SHOULD use the values...' RFC 2119 keyword, line 101: '...* MUST, SHALL, or MANDATORY-This item ...' RFC 2119 keyword, line 103: '...* SHOULD or RECOMMEND-This item should...' RFC 2119 keyword, line 105: '...* MAY or OPTIONAL-This item is truly o...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 1998) is 9591 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 section? '1' on line 173 looks like a reference -- Missing reference section? '4' on line 177 looks like a reference -- Missing reference section? '3' on line 176 looks like a reference -- Missing reference section? '2' on line 174 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. Mark Townsley 2 INTERNET DRAFT IBM Corporation 3 Pratik Gupta 4 IBM Corporation 5 July 1997 6 Expires January 1998 8 Subnet Selection Option for DHCP 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working doc-uments 14 of the Internet Engineering Task Force (IETF), its areas, and its working 15 groups. Note that other groups may also distribute work-ing documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months. 19 Internet-Drafts may be updated, replaced, or obsoleted by other documents 20 at any time. It is not appropriate to use Internet-Drafts as reference 21 material or to cite them other than as a "work-ing draft" or "work in 22 progress." 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 27 munnari.oz.au. 29 Abstract 31 The Subnet Selections option is provided by a DHCP client to DHCP a server 32 as an indication to which subnet or subnets to select an address from for 33 the client's lease. When present, the DHCP server will use this value as an 34 indication to which configured subnet pool of addresses to select from, 35 effectively divorcing the giaddr of its overloaded subnet selection 36 function for a packet forwarded by a DHCP relay agent. The giaddr is 37 retains its function as the address for the DHCP server to send replies to. 39 An application for this new option would be to allow a Network Access 40 Server (NAS) acting as DHCP proxy on behalf of a large number of dial-in 41 users to obtain an address that is in the desired subnet(s) for the dial 42 users without having to configure multiple giaddr values at the NAS, or 43 requiring the NAS to utilize an address within each subnet. 45 1.0 Introduction 47 The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework or 48 passing configuration information to hosts on a TCP/IP network. This 49 configuration information may include a dynamically allocated IP address 50 from a pool of addresses defined at the server. 52 RFC 2131, section 4.3.1 states: 54 "As described in section 4.2, a server MAY, for administrative reasons, 55 assign an address other than the one requested, or may refuse to allocate 56 an address to a particular client even though free addresses are available. 57 Note that, in some network architectures (e.g., internets with more than 58 one IP subnet assigned to a physical network segment), it may be the case 59 that the DHCP client should be assigned an address from a different subnet 60 than the address recorded in 'giaddr'. Thus, DHCP does not require that 61 the client be assigned as address from the subnet in 'giaddr'. A server is 62 free to choose some other subnet, and it is beyond the scope of the DHCP 63 specification to describe ways in which the assigned IP address might be 64 chosen." 66 The subnet selection option provides a way in which the assigned IP address 67 may be chosen. Following is at least one possible application of this. 68 A Network Access Server (NAS) can utilize DHCP as a method for allocating 69 an address to offer an incoming dial user. In this configuration, the NAS 70 generates the appropriate DHCP messages on behalf of the dial user in order 71 to obtain an IP address to be utilized during IPCP negotiation. The dial 72 user is unaware that DHCP was used to obtain the address. Once the PPP link 73 is established, the client is free to use a DHCPINFORM message to obtain 74 any other configuration parameters, if desired. 76 The dial user's connection to the NAS may or may not be associated with a 77 directly connected LAN at the NAS. In the current specification, we must 78 position the NAS to look like a DHCP relay agent in order to dictate to the 79 DHCP server what subnet to offer an address from. This can be accomplished 80 by setting the giaddr to a value within the subnet of our desired address 81 pool, looking as though it were relayed from that associated subnet. This 82 is not a desirable since it forces the NAS to pre-configure one address 83 from each of subnets on which a dial user can exist. 85 When the DHCP server receives the subnet selection option from a client via 86 a relay agent it SHOULD use the values contained in the option as the 87 indicator from which subnet or subnets to choose an available address, 88 while retaining the giaddr address as the address to send DHCP replies to. 89 This allows a NAS acting as a relay agent to choose any internal IP address 90 as the giaddr value without repercussions on the DHCP server's subnet 91 selection. This also allows the NAS to request an address from any one of a 92 list of subnet in a single message, which could be particularly important 93 for a single NAS which may serve a large number of users. Further, the NAS 94 does not itself have to occupy an address for each subnet of one of the 95 DHCP server's address pools. 97 1.1 Conventions 99 The following language conventions are used in the items of specifi-cation 100 in this document: 101 * MUST, SHALL, or MANDATORY-This item is an absolute requirement of the 102 specification. 103 * SHOULD or RECOMMEND-This item should generally be followed for all but 104 exceptional circumstances. 105 * MAY or OPTIONAL-This item is truly optional and may be followed or 106 ignored according to the needs of the implementor. 108 1.2 Terminology 110 DHCP client 111 DHCP client or "client" is an Internet host using DHCP to obtain 112 configuration parameters such as a network address. 113 DHCP server 114 DHCP server of "server" is an Internet host that returns configuration 115 parameters to DHCP clients. 116 Dial User 117 An end-system or router typically attached to an on-demand PSTN or ISDN 118 which is either the initiator or recipient of a call. 119 Network Access Server (NAS) 120 A device providing temporary, on-demand network access to users. 122 his access is point-to-point typically using PSTN or ISDN lines. 123 Internet Protocol Control Protocol (IPCP) 125 A network control protocol defined in [4] for negotiating IP addresses and 126 other IP-related information between two peers connected via the 127 Point-to-Point Protocol [3]. 129 2.0 DHCP Subnet Selection Option Format 131 This option is utilized by a DHCP client to optionally specify the 132 subnet(s) for a DHCP server to offer an IP address from. The information 133 contained in this option consists of one or more pairs of network addresses 134 followed by corresponding subnet masks. 135 The code for this option is TBD. The minimum length of this option is 8, 136 and the length MUST be a multiple of 8. 138 Code Len Address 1 Mask 1 139 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 140 | TBD | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | 141 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 142 Address 2 Mask 2 143 +-----+-----+-----+-----+-----+-----+-----+-----+--- 144 | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ... 145 +-----+-----+-----+-----+-----+-----+-----+-----+--- 147 3.0 Security Considerations 149 DHCP currently provides no authentication or security mechanisms. 150 Potential exposures to attack are discussed in section 7 of the DHCP 151 protocol specification [1]. 153 4.0 Acknowledgments 155 5.0 Author Information 157 W. Mark Townsley 158 IBM Corporation 159 700 Park Office Drive 160 Research Triangle Park, NC 27709 161 wmt@raleigh.ibm.com 162 (919) 543-7522 164 Pratik Gupta 165 IBM Corporation 166 4205 S. Miami Blvd 167 Research Triangle Park, NC 27709 168 pratik_gupta@vnet.ibm.com 169 (919)254-5654 171 6.0 References 173 [1] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131 174 [2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor 175 Extensions", RFC 2132 176 [3] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 177 [4] G. McGregor, "The PPP Internet Protocol Control Protocol 178 (IPCP)", RFC 1332