idnits 2.17.1 draft-haberman-ipngwg-auto-prefix-02.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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 6) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (August 2002) is 7919 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: 'DELEGATOR QUERY' is mentioned on line 110, but not defined == Missing Reference: 'PREFIX DELEGATOR' is mentioned on line 115, but not defined == Missing Reference: 'RFC 2402' is mentioned on line 160, but not defined ** Obsolete undefined reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) == Missing Reference: 'RENEWAL TIMEOUT' is mentioned on line 186, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission B. Haberman 3 Internet Draft J. Martin 4 draft-haberman-ipngwg-auto-prefix-02.txt 5 February 2002 6 Expires August 2002 8 Automatic Prefix Delegation Protocol for 9 Internet Protocol Version 6 (IPv6) 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The expansion of the IP address space provided by IPv6 makes it both 36 possible and reasonable to allocate entire subnets to environments 37 that had been previously limited to a few individual IP addresses. 38 Other protocols such as Neighbor Discovery and Stateless Address 39 Autoconfiguration allow hosts within those subnets to be 40 automatically configured. The router between this subnet and the 41 upstream world requires just one more piece to make this process 42 automatic, a network prefix. 44 This document describes a mechanism for the automated delegation of 45 an IPv6 network prefix. It allows routers to request either a 46 specific prefix or any prefix. Upon authorizing the request the 47 delegating router then returns a prefix and a lifetime for the use 48 of the prefix. Optionally, the delegating and requesting routers 49 can exchange routing protocol information. 51 Haberman, Martin 1 52 1. Introduction 54 This specification defines the Prefix Delegation (PD) protocol for 55 Internet Protocol Version 6 (IPv6). Routers use Prefix Delegation to 56 request a network prefix for use on directly attached networks. 57 Upon receipt of the request, the delegating router may authenticate 58 the request, and will establish if the requested prefix size is 59 acceptable. The delegating router then specifies the prefix for use 60 and the length of time for which that prefix is delegated. 62 The Prefix Delegation protocol supports extensible options. These 63 options may be used to negotiate additional operational parameters, 64 such as routing protocol information. 66 2. Terminology 68 2.1 General 70 This document uses the terminology defined in [RFC 2460] and [RFC 71 2461] and in addition: 73 - Requesting Router - The router that is requesting that a 74 prefix be assigned 76 - Delegating Router - The router that is responding to the 77 prefix request 79 2.2 Requirements 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 83 this document are to be interpreted as described in [RFC 2119]. 85 3. Scope of Work 87 This proposal is meant to give a singly homed leaf router the 88 ability to obtain an IPv6 prefix that can be used within its leaf 89 network. Future revisions of this document may support a more 90 generic approach to dynamic prefix delegation. 92 It is also assumed that the delegating server/router shares a 93 network connection with the requesting router. Future revisions may 94 remove this restriction and allow for either multi-hop messages or a 95 relay function. 97 4. Protocol Overview 99 Haberman, Martin 2 100 The Prefix Delegation protocol defines two new ICMP message types, 101 the Prefix Request and the Prefix Delegation. The Prefix Request is 102 used by the Requesting Router to communicate requests to the 103 Delegating Router. Conversely, the Prefix Delegation is used by the 104 Delegating Router to communicate prefix and error information with 105 the Requesting Router. 107 4.1 Delegator Query 109 The Requesting Router begins the Prefix Delegation process by 110 sending a Prefix Request message of type [DELEGATOR QUERY] to the 111 All-Routers link-local multicast address (FF02::2). 113 Upon receipt of the Delegator query, a Delegating Router determines 114 if it is configured to provide prefixes of the specified scope. If 115 so, it unicasts a Prefix Delegation of type [PREFIX DELEGATOR] to 116 the Requestor. If not, the message is silently discarded. 118 After sending the query, the Requestor waits for Query Interval 119 (Default: 5) seconds for one or more Delegating Routers to respond. 120 If there is no response, the Delegator Query is sent again up to Max 121 Query times (Default: 3). If no response is received, there are no 122 Prefix Delegation services available, and Prefix Delegation has 123 failed. 125 If more than one response is received to the query within the Query 126 Interval, the response with the numerically highest source IP 127 address is used. 129 4.2 Initial Request 131 Once a Delegating Router is chosen, the Requestor sends a Prefix 132 Request message of type Initial Request to the unicast IP address of 133 the chosen Delegating Router. 135 The Requestor may or may not have a Security Association with the 136 Delegating Router, however if Authentication is required and no SA 137 is present, the Delegator will reject the request with an error 138 response indicating that Authentication is required. The Requestor 139 then builds a Security Association with the Delegator and sends 140 another Initial Request including the SA information. 142 If no response is heard within Request Timeout seconds (Default: 5), 143 the Initial Request should be sent again, up to Max Initial Request 144 (Default: 3) tries. If no response is heard, a Delegator Query is 145 sent and the process restarted. If this cycle is repeated Max 146 Delegation Attempts times (Default: 3), Prefix Delegation has 147 failed. 149 4.3 Message Security 151 Haberman, Martin 3 152 Upon receipt of the Prefix Request of any type, the Delegating 153 Router establishes if there is a need for Authentication and/or 154 Encryption, based upon local policy. If either is required and none 155 is provided, the Delegator will return a Prefix Delegation message, 156 with a code of Authentication Required. 158 The building of a Security Association between the Delegator and the 159 Requestor is based on the Authentication and/or Encapsulated 160 Security Payload extension headers defined in [RFC 2402] and [RFC 161 2406]. 163 4.4 Prefix Delegation 165 After the request is verified to be acceptable, the Delegating 166 Router allocates the requested prefix size from its pool of 167 available addresses. The creation and management of that pool is 168 beyond the scope of this document, but it can be supposed that 169 minimalistically a Delegating Router will be statically configured 170 with a fixed pool. If no acceptable prefix is available, a Prefix 171 Delegation message with a code of Prefix Unavailable is returned. 173 The Delegating Router then sends a Prefix Delegation message to the 174 Requesting Router containing a code of Prefix Delegation and all of 175 the prefix information. The Requesting Router then activates the 176 prefix on its interface of choice. 178 4.5 Prefix Refresh 180 All Prefix Delegations have a lifetime that MUST follow the rules 181 defined in Section 4.6.2 of [RFC 2461]. Upon receiving a Prefix 182 Delegation, the requesting router initiates a timer such that before 183 the lifetime expires, the Requesting Router sends a Prefix Request 184 with code=REFRESH directly to the Delegating router. 186 If the Requestor receives no response within [RENEWAL TIMEOUT] 187 seconds (Default: 5), the Renewal Request should be sent again, up 188 to [MAX RENEWAL REQUEST] (Default: 3) tries. If no response is 189 heard the previously allocated prefix is not renewed. 191 A Requesting Router receiving the Prefix Unavailable code, or no 192 response at all, has not had the prefix renewed. It will expire at 193 the end of the initial lifetime. To acquire a new prefix, the 194 Requesting Router must begin anew as described in Section 4.1. 196 4.6 Prefix Return 198 If the Requesting Router no longer requires the use of a prefix, it 199 can return that prefix to the control of the Delegating Router 200 through the use of the Prefix Return code in a Prefix Request. The 201 requesting router sends a Prefix Request directly to the Delegating 202 Router. 204 Haberman, Martin 4 205 Upon receipt and verification (if needed) of this message, the 206 Delegating Router returns the prefix to the pool and issues a Prefix 207 Delegation with a code of Prefix Returned. 209 5. Messages 211 All messages have the following general format: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Code | Checksum | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 + Message Body + 220 | | 222 The following sections describe the specific messages and options 223 used in delegating IPv6 prefixes. 225 5.1 Prefix Request Message 227 The Prefix Request Message is sent to request, renew, or release a 228 prefix. 230 IP Fields 232 Source Address 233 An IP address assigned to the sending interface. 235 Destination Address 236 The All-Routers link-local multicast address (FF02::2)for 237 Delegator Query messages. All other Prefix Request messages 238 should be sent to a unicast address of the Delegating Router. 240 Authentication Header 241 If a Security Association for the IP Authentication Header 242 exists between the sender and the destination address, then 243 the sender SHOULD include this header. No such header is 244 required for the initial prefix request that is multicast, 245 but may be required for further progress. 247 ICMP Fields 249 Type 250 XXX (Where XXX is assigned by IANA) 252 Haberman, Martin 5 253 Code 254 They Type of Request Code: 256 Delegator Query (0) 257 The Delegator Query is used by the Requestor to 258 identify potential Delegating Routers. It is sent to 259 the All-Routers link-local multicast address with no 260 Authentication Header. 262 Initial Request (1) 263 The Initial Request is used to initiate the request 264 process. It is sent to the unicast IP address of the 265 Delegating Router, and may carry an Authentication 266 Header. Unused fields MUST be set to zero. An Initial 267 Request code MAY contain a Prefix Option. 269 Renewal Request (2) 270 The Renewal Request is used to renew a prefix that has 271 been previously allocated. It is sent to a unicast IP 272 address of the Delegating Router and may carry an 273 Authentication Header. A Renewal Request code MUST 274 contain at least one Prefix Option. 276 Prefix Return (3) 277 The Prefix Return is used to return an unused prefix, 278 or portion of a prefix to the control of the Delegating 279 Router. It is sent to a unicast IP address of the 280 Delegating Router and may carry an Authentication 281 Header. A Prefix Return code MUST contain at least one 282 Prefix Option. 284 Checksum 285 The ICMP checksum as defined in [RFC 2463]. 287 5.2 Prefix Delegation Message Format 289 The Prefix Delegation Messages are sent to provide the addresses of 290 available Prefix Delegators, to provide prefix data, and for error 291 returns. 293 IP Fields 295 Source Address 296 An IP address assigned to the sending interface. 298 Destination Address 299 The IP address of the Requestor as specified by the IP Source 300 Address in the Prefix Request message. 302 Authentication Header 304 Haberman, Martin 6 305 If a Security Association for the IP Authentication Header 306 exists between the sender and the destination address, then 307 the sender SHOULD include this header. 309 ICMP Fields 311 Type 312 XXX+1 (Where XXX+1 is assigned by IANA) 314 Code 315 The Type of Response Code: 317 Prefix Delegator (0) 318 The Prefix Delegator is used by the Delegator to inform 319 the Requestor that it is available to provide prefixes 320 of the desired type. It is sent to the unicast IP 321 address in the Source Address portion of the Prefix 322 Request packet. Unused fields MUST be set to zero. 324 Authentication Required (1) 325 The Authentication Required message indicates to the 326 Requestor that a Security Association must be 327 established before a prefix can be delegated. It is 328 sent to the unicast IP address in the Source Address 329 portion of the Prefix Request packet. Unused fields 330 MUST be set to zero. 332 Authorization Failed (2) 333 The Authorization Failed message indicates to the 334 Requestor that either it is not authorized to request a 335 prefix, or that the prefix requested fell outside of 336 local policy. It is sent to the unicast IP address in 337 the Source Address portion of the Prefix Request 338 packet. Unused fields MUST be set to zero. 340 Prefix Unavailable (3) 341 The Prefix Unavailable indicates that the Prefix 342 Request was acceptable, but the Delegator does not have 343 sufficient available address space to fulfill the 344 request. It is sent to the unicast IP address in the 345 Source Address portion of the Prefix Request packet. 346 Unused fields MUST be set to zero. 348 Prefix Delegated (4) 349 The Prefix Delegated message actually provides the 350 prefix information that the Requestor has requested. It 351 is sent to the unicast IP address in the Source Address 352 portion of the Prefix Request packet. For this message, 353 a Prefix Option MUST be included. 355 Prefix Returned (5) 357 Haberman, Martin 7 358 The Prefix Return is used to confirm the return of a 359 prefix. It is sent to the unicast IP address in the 360 Source Address portion of the Prefix Request packet. 361 For this message, the Prefix Option MUST be included. 363 Checksum 364 The ICMP checksum. 366 5.3 Prefix Option 368 The Subnet Prefix Option is used to relay prefix information between 369 Requestors and Delegators. It has the following format: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Type | Length | Reserved | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Prefix Lifetime | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 + + 380 | | 381 + Prefix + 382 | | 383 + + 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Prefix Option Fields 389 Type = 0x01 390 This field identifies the presence of a subnet prefix. This 391 option MUST follow either a Prefix Request header or a Prefix 392 Delegation header. 394 Length 395 The length of the prefix contained in the option. 397 Reserved 398 This field is unused. It MUST be initialized to zero by the 399 sender and MUST be ignored by the receiver. 401 Prefix Lifetime 402 The lifetime of the prefix contained in the option. 404 IPv6 Prefix 405 The Prefix field is used to carry a subnet prefix. The host 406 portion of the IP address MUST be padded with zeros. 408 Haberman, Martin 8 409 6. Security Considerations 411 The ability to automate the delegation of prefixes opens several 412 security vulnerabilities. Rogue delegators can issue bogus prefixes 413 to requestors. This may cause denial of service due to 414 unreachability. Rogue requestors may consume valuable resources 415 from legitimate delegators, thus denying others the use of the 416 prefixes. For these reasons, the use of IPSec-based Authentication 417 and/or Encryption is suggested. 419 7. To Do's 421 - Additional security discussion 422 - Relay functionality 423 - Routing capabilities option 425 8. Acknowledgements 427 We would like to acknowledge and thank Jun-ichiro itojun Hagino, 428 Dave Thaler, Yamasaki Toshi, Ole Troan, and Kazuaki Tsuchiya for 429 their feedback and suggestions on this document. 431 9. References 433 [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 434 (IPv6) Specification", RFC 2460, December 1998. 436 [RFC 2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 437 Discovery for IP Version 6 (IPv6)", RFC 2461, December 438 1998. 440 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 441 Requirement Levels", RFC 2119, BCP 14, March 1997. 443 [RFC 2463] A. Conta and S. Deering, "Internet Control Message 444 Protocol (ICMPv6) for the Internet Protocol Version 6 445 (IPv6) Specification", RFC 2463, December 1998. 447 Authors' Addresses 449 Brian Haberman 450 haberman@lorien.sc.innovationslab.net 452 Jim Martin 453 jim@interop.net 455 Haberman, Martin 9