idnits 2.17.00 (12 Aug 2021) /tmp/idnits11459/draft-haberman-ipngwg-auto-prefix-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 expiration date. The document expiration date should appear on the first and last page. ** 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 11 longer pages, the longest (page 3) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 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 (November 2000) is 7857 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: 'ADDR-ARCH' is mentioned on line 87, but not defined == Missing Reference: 'DELEGATOR QUERY' is mentioned on line 123, but not defined == Missing Reference: 'RENEWAL TIMEOUT' is mentioned on line 208, but not defined == Unused Reference: 'RFC 2461' is defined on line 516, but no explicit reference was found in the text ** 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: 10 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-00.txt Nortel Networks 5 November 2000 7 Automatic Prefix Delegation Protocol for 8 Internet Protocol Version 6 (IPv6) 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The expansion of the IP address space provided by IPv6 makes it both 35 possible and reasonable to allocate entire subnets to environments 36 that had been previously limited to a few individual IP addresses. 37 Other protocols such as Neighbor Discovery and Stateless Address 38 Autoconfiguration allow hosts within those subnets to be 39 automatically configured. The router between this subnet and the 40 upstream world requires just one more piece to make this process 41 automatic, a network prefix. 43 This document describes a mechanism for the automated delegation of 44 an IPv6 network prefix. It allows routers to request a specific size 45 prefix and inform the upstream router of the routing protocols of 46 which it is capable. Upon authorizing the request the delegating 47 router then returns a prefix, the desired routing protocol, and a 48 lifetime for the use of the prefix. 50 Haberman, Martin 1 51 1. Introduction 53 This specification defines the Prefix Delegation (PD) protocol for 54 Internet Protocol Version 6 (IPv6). Routers use Prefix Delegation to 55 request a network prefix for use on directly attached networks. 56 Prefix Delegation also allows the requesting router to specify the 57 routing protocols in which it is capable of participating. Upon 58 receipt of the request, the delegating router may authenticate the 59 request, and will establish if the requested prefix size is 60 acceptable. The delegating router then specifies the prefix for use, 61 the length of time for which that prefix is delegated, and the 62 routing protocol to be used. 64 Unless specified otherwise (in a document that covers operating IP 65 over a particular link type) this document applies to all link 66 types. However, because PD uses link-layer multicast, it is possible 67 that on some link types (e.g., NBMA links) alternative mechanisms to 68 implement PD must be specified (in the appropriate document covering 69 the operation of IP over a particular link type). 71 2. Terminology 73 2.1 General 75 This document uses the terminology defined in [RFC 2460] and [RFC 76 2461] and in addition: 78 Requesting Router - The router that is requesting that a 79 prefix be assigned 81 Delegating Router - The router that is responding to the 82 prefix request 84 2.2 Addresses 86 Prefix Delegation makes use of a number of different addresses 87 defined in [ADDR-ARCH], including: 89 Global address - A unicast address having global scope 91 2.3 Requirements 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in [RFC 2119]. 97 3. Scope of Work 99 This proposal is meant to give a singly homed leaf router the 100 ability to obtain an IPv6 prefix that can be used within its leaf 102 Haberman, Martin 2 103 network. Future revisions of this document may support a more 104 generic approach to dynamic prefix delegation. 106 It is also assumed that the delegating server/router shares a 107 network connection with the requesting router. Future revisions may 108 remove this restriction and allow for either multi-hop messages or a 109 relay function. 111 4. Protocol Overview 113 The Prefix Delegation protocol defines two new ICMP message types, 114 the Prefix Request and the Prefix Delegation. The Prefix Request is 115 used by the Requesting Router to communicate requests to the 116 Delegating Router. Conversely, the Prefix Delegation is used by the 117 Delegating Router to communicate prefix and error information with 118 the Requesting Router. 120 4.1 Delegator Query 122 The Requesting Router begins the Prefix Delegation process by 123 sending a Prefix Request message of type [DELEGATOR QUERY] to the 124 ALL-DELEGATORS link-local multicast address (XXXX::XX). 126 Upon receipt of the Delegator query, a Delegating Router determines 127 if it is configured to provide prefixes of the specified scope. If 128 so, it unicasts a Prefix Delegation of type Prefix Delegator to the 129 Requestor. If not, the message is silently discarded. 131 After sending the query, the Requestor waits for Query Interval 132 (Default: 5) seconds for one or more Delegating Routers to respond. 133 If there is no response, the Delegator Query is sent again up to Max 134 Query times (Default: 3). If no response is received, there are no 135 Prefix Delegation services available, and Prefix Delegation has 136 failed. 138 If more than one response is received to the query, the response 139 with the numerically highest source IP address is used. 141 4.2 Initial Request 143 Once a Delegating Router is chosen, the Requestor sends a Prefix 144 Request message of type Initial Request to the unicast IP address of 145 the Delegating Router. 147 The Requestor may or may not have a Security Association with the 148 Delegating Router, however if Authentication is required and no SA 149 is present, the Delegator will reject the request with an error 150 response indicating that Authentication is required. The Requestor 151 then builds a Security Association with the Delegator and sends 152 another Initial Request including the SA information. 154 Haberman, Martin 3 155 If no response is heard within Request Timeout seconds (Default: 5), 156 the Initial Request should be sent again, up to Max Initial Request 157 (Default: 3) tries. If no response is heard, a Delegator Query is 158 sent and the process restarted. If this cycle is repeated Max 159 Delegation Attempts times (Default: 3), Prefix Delegation has 160 failed. 162 4.3 Authentication and Authorization 164 Upon receipt of the Prefix Request of any type, the Delegating 165 Router establishes if there is a need for Authentication, based upon 166 local policy. If Authentication is required and none is provided, 167 the Delegator will return a Prefix Delegation message, with a code 168 of Authentication Required. 170 Once the authentication credentials of the requestor, if present, 171 are established, any request that requires the allocation of a 172 prefix must be checked for Authorization. Authorization is 173 established by verifying that the requested prefix length for the 174 specific Requestor is acceptable by locally configured policy. If 175 the prefix length requested falls outside of policy, a Prefix 176 Delegation error message of type Not Authorized is returned. 178 4.4 Prefix Delegation 180 After the request is verified to be acceptable, the Delegating 181 Router allocates the requested prefix size from its pool of 182 available addresses. The creation and management of that pool is 183 beyond the scope of this document, but it can be supposed that 184 minimalistically a Delegating Router will be statically configured 185 with a fixed pool. If no acceptable prefix is available, a Prefix 186 Delegation message with a code of Prefix Unavailable is returned. 188 The Delegating Router then compares the list of available routing 189 protocols in the Request against its own capabilities and the local 190 policies regarding routing. For the purposes of this comparison, 191 static routes are considered a routing protocol. If no acceptable 192 match is found, static routes are used. 194 The Delegating Router then sends a Prefix Delegation message to the 195 Requesting Router containing a code of Prefix Delegation and all of 196 the prefix and routing information. The Delegating router then 197 activates the negotiated protocol on the interface to which the 198 Requestor is attached. 200 4.5 Prefix Refresh 202 All Prefix Delegations have a finite lifetime. Upon receiving a 203 Prefix Delegation, the requesting router initiates a timer such that 204 before the lifetime is expired, the Requesting Router sends a Prefix 205 Request with a Renewal Refresh code directly to the Delegating router. 207 Haberman, Martin 4 208 If the Requestor receives no response within [RENEWAL TIMEOUT] 209 seconds (Default: 5), the Renewal Request should be sent again, up 210 to [MAX RENEWAL REQUEST] (Default: 3) tries. If no response is 211 heard the previously allocated prefix is not renewed. 213 A Requesting Router receiving the Prefix Unavailable code, or no 214 response at all, has not had the prefix renewed. It will expire at 215 the end of the initial lifetime. To acquire a new prefix, the 216 Requesting Router must begin anew as described in Section 4.1. 218 4.6 Prefix Return 220 If the Requesting Router no longer requires the use of a prefix, it 221 can return that prefix to the control of the Delegating Router 222 through the use of the Prefix Return code in a Prefix Request. The 223 requesting router sends a Prefix Request directly to the Delegating 224 Router. 226 Upon receipt and verification (if needed) of this message, the 227 Delegating Router returns the prefix to the pool and issues a Prefix 228 Delegation with a code of Prefix Returned. 230 5. Messages 232 All messages have the following general format: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type | Code | Checksum | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 + Message Body + 241 | | 243 5.1 Prefix Request Message 245 The Prefix Request Message is sent to request, renew, or release a 246 prefix. 248 Haberman, Martin 5 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Code | Checksum | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |S|Prefix Length| Routing Capabilities | Reserved | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 + + 258 | | 259 + IPv6 Prefix + 260 | | 261 + + 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 IP Fields 267 Source Address 268 An IP address assigned to the sending interface. 270 Destination Address 271 The ALL-DELEGATORS link-local multicast address (XXXX::XX)for 272 Delegator Query messages. All other Prefix Request messages 273 should be sent to a unicast address of the Delegating Router. 275 Authentication Header 276 If a Security Association for the IP Authentication Header 277 exists between the sender and the destination address, then 278 the sender SHOULD include this header. No such header is 279 required for the initial prefix request that is multicast, 280 but may be required for further progress. 282 ICMP Fields 284 Type 285 XXX (Where XXX is assigned by IANA) 287 Code 288 They Type of Request Code: 290 Delegator Query (0) 291 The Delegator Query is used by the Requestor to 292 identify potential Delegating Routers. It is sent to 293 the all-delegators link-local multicast address with no 294 Authentication Header. For this Query, the Scope field 295 is required. Unused fields MUST be set to zero. 297 Initial Request (1) 298 The Initial Request is used to initiate the request 299 process. It is sent to the unicast IP address of the 300 Delegating Router, and may carry an Authentication 302 Haberman, Martin 6 303 Header. For this initial request, the Scope, Prefix 304 Length, and Routing Capabilities fields are required. 305 Unused fields MUST be set to zero. 307 Renewal Request (2) 308 The Renewal Request is used to renew a prefix that has 309 been previously allocated. It is sent to a unicast IP 310 address of the Delegating Router and may carry an 311 Authentication Header. For the renewal, the Scope, 312 Prefix Length, Routing Capabilities, and Prefix fields 313 are required. 315 Prefix Return (3) 316 The Prefix Return is used to return an unused prefix, 317 or portion of a prefix to the control of the Delegating 318 Router. It is sent to a unicast IP address of the 319 Delegating Router and may carry an Authentication 320 Header. For the Return, the Scope, Prefix Length, and 321 Prefix fields are required. Unused fields MUST be set 322 to zero. 324 Checksum 325 The ICMP checksum as defined in [RFC 2463]. 327 Prefix Request Fields 329 S 330 A one bit Scope Flag. A value of zero (0) indicates that the 331 request is for a prefix of Global Scope, a one (1) indicates 332 site-local. 334 Prefix Length 335 The length of the prefix being requested, renewed, or 336 released. 338 Routing Capabilities 339 This bit-field allows the requestor to specify the routing 340 protocols in which it is capable of participating. For the 341 purposes of this field, a static route is considered a 342 routing protocol. 344 At this time, the only defined value is zero (0), indicating 345 that the requestor is capable of static routes. This is an 346 area for further work. 348 Reserved 349 This field is unused. It MUST be initialized to zero by the 350 sender and MUST be ignored by the receiver. 352 IPv6 Prefix 354 Haberman, Martin 7 355 The Prefix field is used to carry a previously assigned 356 prefix. The host portion of the IP address MUST be padded 357 with zeros. 359 5.2 Prefix Delegation Message 361 The Prefix Delegation Messages are sent to provide the addresses of 362 available Prefix Delegators, to provide prefix and routing data, and 363 for error returns. 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type | Code | Checksum | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |S|Prefix Length| Lifetime | Rt Proto | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 + + 374 | | 375 + IPv6 Prefix + 376 | | 377 + + 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Rt Info Length | Rt Info . . . . 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | 384 IP Fields 386 Source Address 387 An IP address assigned to the sending interface. 389 Destination Address 390 The IP address of the Requestor as specified by the Source 391 Address of the Prefix Request message. 393 Authentication Header 394 If a Security Association for the IP Authentication Header 395 exists between the sender and the destination address, then 396 the sender SHOULD include this header. 398 ICMP Fields 400 Type 401 XXX+1 (Where XXX+1 is assigned by IANA) 403 Code 404 The Type of Response Code: 406 Haberman, Martin 8 407 Prefix Delegator (0) 408 The Prefix Delegator is used by the Delegator to inform 409 the Requestor that it is available to provide prefixes 410 of the desired type. It is sent to the unicast IP 411 address in the Source Address portion of the Prefix 412 Request packet. For this Response, the Scope field is 413 required. Unused fields MUST be set to zero. 415 Authentication Required (1) 416 The Authentication Required message indicates to the 417 Requestor that a Security Association must be 418 established before a prefix can be delegated. It is 419 sent to the unicast IP address in the Source Address 420 portion of the Prefix Request packet. For this message, 421 no additional fields are required. Unused fields MUST 422 be set to zero. 424 Authorization Failed (2) 425 The Authorization Failed message indicates to the 426 Requestor that either it is not authorized to request a 427 prefix, or that the prefix requested fell outside of 428 local policy. It is sent to the unicast IP address in 429 the Source Address portion of the Prefix Request 430 packet. For this message, no additional fields are 431 required. Unused fields MUST be set to zero. 433 Prefix Unavailable (3) 434 The Prefix Unavailable indicates that the Prefix 435 Request was acceptable, but the Delegator does not have 436 sufficient available address space to fulfill the 437 request. It is sent to the unicast IP address in the 438 Source Address portion of the Prefix Request packet. 439 For this message, no additional fields are required. 440 Unused fields MUST be set to zero. 442 Prefix Delegated (4) 443 The Prefix Delegated message actually provides the 444 prefix information that the Requestor has requested. It 445 is sent to the unicast IP address in the Source Address 446 portion of the Prefix Request packet. For this message, 447 all fields are required. 449 Prefix Returned (5) 450 The Prefix Return is used to confirm the return of a 451 prefix. It is sent to the unicast IP address in the 452 Source Address portion of the Prefix Request packet. 453 For this message, the Prefix Length and IPv6 Prefix 454 fields are required. 456 Checksum 457 The ICMP checksum. 459 Haberman, Martin 9 460 Prefix Delegation Fields 462 S 463 A one bit Scope Flag. A value of zero (0) indicates that the 464 response is for a prefix of Global Scope, a one (1) indicates 465 site-local. 467 Prefix Length 468 The length of the prefix being provided. 470 Lifetime 471 The time (in seconds) that the Requestor is permitted to use 472 the allocated prefix. At the end of this period, the 473 Delegator assumes control of the prefix. This lifetime can be 474 extended through the renewal process. 476 Rt Proto 477 This field specifies the routing protocol in which the 478 Requestor should participate. 480 At this time, the only defined value is zero, for Static 481 Routes. This is an area for further development of this 482 document. 484 IPv6 Prefix 485 The Prefix field is used to carry the assigned prefix. The 486 host portion of the IP address MUST be padded with zeros. 488 Rt Info Length 489 The length, in octets, of the Routing Information field. At 490 this time, since Static is the only defined protocol; this 491 field should have a value of zero. 493 Routing Information 494 This field carries protocol specific information to allow the 495 Requesting router to configure itself to participate in 496 routing. 498 This field will be described in later versions of this 499 document. At this time, since Static is the only defined 500 protocol; this field should be zero length. 502 6. To Do's 504 - Additional security discussion 505 - Expand routing protocol negotiation 506 - Multiple hops between requestor and delegator 507 - Cascading delegations 508 - Removal of leaf network restriction 510 Haberman, Martin 10 511 7. References 513 [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 514 (IPv6) Specification", RFC 2460, December 1998. 516 [RFC 2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 517 Discovery for IP Version 6 (IPv6)", RFC 2461, December 518 1998. 520 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 521 Requirement Levels", RFC 2119, BCP 14, March 1997. 523 [RFC 2463] A. Conta and S. Deering, "Internet Control Message 524 Protocol (ICMPv6) for the Internet Protocol Version 6 525 (IPv6) Specification", RFC 2463, December 1998. 527 Authors' Addresses 529 Brian Haberman 530 Nortel Networks 531 4309 Emperor Blvd. 532 Suite 200 533 Durham, NC 27703 535 Phone : 1-919-992-4439 536 Email : haberman@nortelnetworks.com 538 Jim Martin 539 Nortel Networks 540 4401 Great America Parkway 541 Santa Clara, Ca 95054 543 Phone : 1-408-495-3792 544 Email : jrm@nortelnetworks.com 546 Haberman, Martin 11