idnits 2.17.1 draft-ietf-ipngwg-router-renum-06.txt: ** The Abstract section seems to be numbered 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-27) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 642 has weird spacing: '...pLength mus...' == Line 646 has weird spacing: '...atchLen mus...' == Line 863 has weird spacing: '...ination wild...' -- 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 10, 1998) is 9300 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: 'SAA' is mentioned on line 496, but not defined -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch-v2 is -06, but you're referring to -07. -- Unexpected draft version: The latest known version of draft-ietf-ipsec-auth-header is -06, but you're referring to -07. -- Unexpected draft version: The latest known version of draft-ietf-ipsec-esp-v2 is -05, but you're referring to -06. ** Obsolete normative reference: RFC 2434 (ref. 'IANACON') (Obsoleted by RFC 5226) -- Unexpected draft version: The latest known version of draft-ietf-ipsec-arch-sec is -06, but you're referring to -07. -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec-v2 is -01, but you're referring to -02. -- Possible downref: Non-RFC (?) normative reference: ref. 'IPV6MIB' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-discovery-v2 is -02, but you're referring to -03. Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPng Working Group Matt Crawford 2 Internet Draft Fermilab 3 November 10, 1998 5 Router Renumbering for IPv6 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet- Drafts as 18 reference material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Distribution of this memo is unlimited. 28 1. Abstract 30 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently 31 make initial assignments of address prefixes to hosts. Aside from 32 the problem of connection survival across a renumbering event, these 33 two mechanisms also simplify the reconfiguration of hosts when the 34 set of valid prefixes changes. 36 This document defines a mechanism called Router Renumbering ('RR') 37 which allows address prefixes on routers to be configured and 38 reconfigured almost as easily as the combination of Neighbor 39 Discovery and Address Autoconfiguration works for hosts. It 40 provides a means for a network manager to make updates to the 41 prefixes used by and advertised by IPv6 routers throughout a site. 43 Table of Contents 45 Status of this Memo ............................................... 1 47 1. Abstract ...................................................... 1 49 2. Functional Overview ........................................... 3 51 3. Definitions ................................................... 4 52 3.1. Terminology ............................................. 4 53 3.2. Requirements ............................................ 5 55 4. Message Format ................................................ 5 56 4.1. Router Renumbering Header ............................... 7 57 4.2. Message Body -- Command Message ......................... 9 58 4.2.1. Prefix Control Operation .......................... 9 59 4.2.1.1. Match-Prefix Part ........................... 9 60 4.2.1.2. Use-Prefix Part ............................. 10 61 4.3. Message Body -- Result Message .......................... 12 63 5. Message Processing ............................................ 13 64 5.1. Header Check ............................................ 13 65 5.2. Bounds Check ............................................ 14 66 5.3. Execution ............................................... 15 67 5.4. Summary of Effects ...................................... 17 69 6. Sequence Number Reset ......................................... 17 71 7. IANA Considerations ........................................... 18 73 8. Security Considerations ....................................... 18 74 8.1. Security Policy and Association Database Entries ........ 18 76 9. Usage Examples ................................................ 20 77 9.1. Maintaining Global-Scope Prefixes ....................... 20 78 9.2. Renumbering a Subnet .................................... 21 80 10. Acknowledgments .............................................. 22 82 11. References ................................................... 22 84 12. Author's Address ............................................. 23 85 2. Functional Overview 87 Router Renumbering Command packets contain a sequence of Prefix 88 Control Operations (PCOs). Each PCO specifies an operation, a 89 Match-Prefix, and zero or more Use-Prefixes. A router processes 90 each PCO in sequence, checking each of its interfaces for an address 91 or prefix which matches the Match-Prefix. For every interface on 92 which a match is found, the operation is applied. The operation is 93 one of ADD, CHANGE, or SET-GLOBAL to instruct the router to 94 respectively add the Use-Prefixes to the set of configured prefixes, 95 remove the prefix which matched the Match-Prefix and replace it with 96 the Use-Prefixes, or replace all global-scope prefixes with the 97 Use-Prefixes. If the set of Use-Prefixes in the PCO is empty, the 98 ADD operation does nothing and the other two reduce to deletions. 100 Additional information for each Use-Prefix is included in the Prefix 101 Control Operation: the valid and preferred lifetimes to be included 102 in Router Advertisement Prefix Information Options [ND], and either 103 the L and A flags for the same option, or an indication that they 104 are to be copied from the prefix that matched the Match-Prefix. 106 It is possible to instruct routers to create new prefixes by 107 combining the Use-Prefixes in a PCO with some portion of the 108 existing prefix which matched the Match-Prefix. This simplifies 109 certain operations which are expected to be among the most common. 110 For every Use-Prefix, the PCO specifies a number of bits which 111 should be copied from the existing address or prefix which matched 112 the Match-Prefix and appended to the use-prefix prior to configuring 113 the new prefix on the interface. The copied bits are zero or more 114 bits from the positions immediately after the length of the Use- 115 Prefix. If subnetting information is in the same portion of the old 116 and new prefixes, this synthesis allows a single Prefix Control 117 Operation to define a new global prefix on every router in a site, 118 while preserving the subnetting structure. 120 Because of the power of the Router Renumbering mechanism, each RR 121 message includes a sequence number to guard against replays, and is 122 required to be authenticated and integrity-checked. Each single 123 Prefix Control Operation is idempotent and so could be retransmitted 124 for improved reliability, as long as the sequence number is current, 125 without concern about multiple processing. However, non-idempotent 126 combinations of PCOs can easily be constructed and messages 127 containing such combinations could not be safely reprocessed. 128 Therefore, all routers are required to guard against processing an 129 RR message more than once. To allow reliable verification that 130 Commands have been received and processed by routers, a mechanism 131 for duplicate-command notification to the management station is 132 included. 134 Possibly a network manager will want to perform more renumbering, or 135 exercise more detailed control, than can be expressed in a single 136 Router Renumbering packet on the available media. The RR mechanism 137 is most powerful when RR packets are multicast, so IP fragmentation 138 is undesirable. For these reasons, each RR packet contains a 139 "Segment Number". All RR packets which have a Sequence Number 140 greater than or equal to the highest value seen are valid and must 141 be processed. However, a router must keep track of the Segment 142 Numbers of RR messages already processed and avoid reprocessing a 143 message whose Sequence Number and Segment Number match a previously 144 processed message. (This list of processed segment numbers is reset 145 when a new highest Sequence Number is seen.) 147 The Segment Number does not impose an ordering on packet processing. 148 If a specific sequence of operations is desired, it may be achieved 149 by ordering the PCOs in a single RR Command message or through the 150 Sequence Number field. 152 There is a "Test" flag which indicates that all routers should 153 simulate processing of the RR message and not perform any actual 154 reconfiguration. A separate "Report" flag instructs routers to send 155 a Router Renumbering Result message back to the source of the RR 156 Command message indicating the actual or simulated result of the 157 operations in the RR Command message. 159 The effect or simulated effect of an RR Command message may also be 160 reported to network management by means outside the scope of this 161 document, regardless of the value of the "Report" flag. 163 3. Definitions 165 3.1. Terminology 167 Address 168 This term always refers to a 128-bit IPv6 address [AARCH]. When 169 referring to bits within an address, they are numbered from 0 to 170 127, with bit 0 being the first bit of the Format Prefix. 172 Prefix 173 A prefix can be understood as an address plus a length, the 174 latter being an integer in the range 0 to 128 indicating how many 175 leading bits are significant. When referring to bits within a 176 prefix, they are numbered in the same way as the bits of an 177 address. For example, the significant bits of a prefix whose 178 length is L are the bits numbered 0 through L-1, inclusive. 180 Match 181 An address A "matches" a prefix P whose length is L if the first 182 L bits of A are identical with the first L bits of P. (Every 183 address matches a prefix of length 0.) A prefix P1 with length 184 L1 matches a prefix P2 of length L2 if L1 >= L2 and the first L2 185 bits of P1 and P2 are identical. 187 Prefix Control Operation 188 This is the smallest individual unit of Router Renumbering 189 operation. A Router Renumbering Command packet includes zero or 190 more of these, each comprising one matching condition, called a 191 Match-Prefix Part, and zero or more substitution specifications, 192 called Use-Prefix Parts. 194 Match-Prefix 195 This is a Prefix against which a router compares the addresses 196 and prefixes configured on its interfaces. 198 Use-Prefix 199 The prefix and associated information which is to be configured 200 on a router interface when certain conditions are met. 202 Matched Prefix 203 The existing prefix or address which matched a Match-Prefix. 205 New Prefix 206 A prefix constructed from a Use-Prefix, possibly including some 207 of the Matched Prefix. 209 Recorded Sequence Number 210 The highest sequence number found in a valid message MUST be 211 recorded in non-volatile storage. 213 Note that "matches" is a transitive relation but not symmetric. 214 If two prefixes match each other, they are identical. 216 3.2. Requirements 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in [KWORD]. 222 4. Message Format 224 There are two types of Router Renumbering messages: Commands, which 225 are sent to routers, and Results, which are sent by routers. A 226 third message type is used to synchronize a reset of the Recorded 227 Sequence Number with the cancellation of cryptographic keys. The 228 three types of messages are distinguished the ICMPv6 "Code" field 229 and differ in the contents of the "Message Body" field. 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 / IPv6 header, extension headers / 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 / ICMPv6 & RR Header (16 octets) / 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 / RR Message Body / 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Router Renumbering Message Format 247 Router Renumbering messages are carried in ICMPv6 packets with 248 Type = 138. The RR message comprises an RR Header, containing the 249 ICMPv6 header, the sequence and segment numbers and other 250 information, and the RR Message Body, of variable length. 252 All fields marked "reserved" or "res" MUST be set to zero on 253 generation of an RR message. 255 All implementations which generate Router Renumbering Command 256 messages MUST support sending them to the All Routers multicast 257 address with link and site scopes, and to unicast addresses of 258 link-local and site-local formats. All routers MUST be capable of 259 receiving RR Commands sent to those multicast addresses and to any 260 of their link local and site local unicast addresses. 261 Implementations SHOULD support sending and receiving RR messages 262 addressed to other unicast addresses. An implementation which is 263 both a sender and receiver of RR commands SHOULD support use of the 264 All Routers multicast address with node scope. 266 Data authentication and message integrity MUST be provided for all 267 Router Renumbering Command messages by appropriate IP Security 268 [IPSEC] means. The integrity assurance must include the IPv6 269 destination address and the RR Header and Message Body. See section 270 8, "Security Considerations". 272 The use of authentication for Router Renumbering Result messages is 273 RECOMMENDED. 275 4.1. Router Renumbering Header 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Code | Checksum | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | SequenceNumber | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | SegmentNumber | Flags | MaxDelay | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | reserved | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Fields: 291 Type 138 (decimal), the ICMPv6 type value assigned to Router 292 Renumbering 294 Code 0 for a Router Renumbering Command 295 1 for a Router Renumbering Result 296 255 for a Sequence Number Reset. 297 The Sequence Number Reset is described in section 6. 299 Checksum The ICMPv6 checksum, as specified in [ICMPV6]. The 300 checksum covers the IPv6 pseudo-header and all fields of 301 the RR message from the Type field onward. 303 SequenceNumber 304 An unsigned 32-bit sequence number. The sequence number 305 MUST be non-decreasing between Sequence Number Resets. 307 SegmentNumber 308 An unsigned 8-bit field which enumerates different valid 309 RR messages having the same SequenceNumber. No ordering 310 among RR messages is imposed by the SegmentNumber. 312 Flags A combination of one-bit flags. Six are defined and two 313 bits are reserved. 315 +-+-+-+-+-+-+-+-+ 316 |T|R|A|S|P| res | 317 +-+-+-+-+-+-+-+-+ 319 The flags T, R, A and S have defined meanings in an RR 320 Command message. In a Result message they MUST be 321 copied from the corresponding Command. The P flag is 322 meaningful only in a Result message and MUST be zero in 323 a Command. 325 T 0 indicates that the router configuration is to be 326 modified; 327 1 indicates a "Test" message: processing is to be 328 simulated and no configuration changes are to be 329 made. 331 R 0 indicates that a Result message MUST NOT be sent 332 (but other forms of logging are not precluded); 333 1 indicates that the router MUST send a Result 334 message upon completion of processing the Command 335 message; 337 A 0 indicates that the Command MUST NOT be applied to 338 interfaces which are administratively shut down; 339 1 indicates that the Command MUST be applied to 340 interfaces regardless of administrative shutdown 341 status. 343 S This flag MUST be ignored unless the router treats 344 interfaces as belonging to different "sites". 345 0 indicates that the Command MUST be applied to 346 interfaces regardless of which site they belong 347 to; 348 1 indicates that the Command MUST be applied only to 349 interfaces which belong to the same site as the 350 interface to which the Command is addressed. If 351 the destination address is appropriate for 352 interfaces belonging to more than one site, then 353 the Command MUST be applied only to interfaces 354 belonging to the same site as the interface on 355 which the Command was received. 357 P 0 indicates that the Result message contains the 358 complete report of processing the Command; 359 1 indicates that the Command message was previously 360 processed (and is not a Test) and the responding 361 router is not processing it again. This Result 362 message MAY have an empty body. 364 MaxDelay An unsigned 16-bit field specifying the maximum time, in 365 milliseconds, by which a router MUST delay sending any 366 reply to this Command. Implementations MAY generate the 367 random delay between 0 and MaxDelay milliseconds with a 368 finer granularity than 1ms. 370 4.2. Message Body -- Command Message 372 The body of an RR Command message is a sequence of zero or more 373 Prefix Control Operations, each of variable length. The end of the 374 sequence MAY be inferred from the IPv6 length and the lengths of 375 extension headers which precede the ICMPv6 header. 377 4.2.1. Prefix Control Operation 379 A Prefix Control Operation has one Match-Prefix Part of 24 octets, 380 followed by zero or more Use-Prefix Parts of 32 octets each. 382 4.2.1.1. Match-Prefix Part 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | OpCode | OpLength | Ordinal | MatchLen | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | MinLen | MaxLen | reserved | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 +- -+ 393 | | 394 +- MatchPrefix -+ 395 | | 396 +- -+ 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Fields: 402 OpCode An unsigned 8-bit field specifying the operation to be 403 performed when the associated MatchPrefix matches an 404 interface's prefix or address. Values are: 406 1 the ADD operation 408 2 the CHANGE operation 410 3 the SET-GLOBAL operation 412 OpLength The total length of this Prefix Control Operation, in 413 units of 8 octets. A valid OpLength will always be of 414 the form 4N+3, with N equal to the number of UsePrefix 415 parts (possibly zero). 417 Ordinal An 8-bit field which MUST have a different value in each 418 Prefix Control Operation contained in a given RR Command 419 message. The value is otherwise unconstrained. 421 MatchLen An 8-bit unsigned integer between 0 and 128 inclusive 422 specifying the number of initial bits of MatchPrefix 423 which are significant in matching. 425 MinLen An 8-bit unsigned integer specifying the minimum length 426 which any configured prefix must have in order to be 427 eligible for testing against the MatchPrefix. 429 MaxLen An 8-bit unsigned integer specifying the maximum length 430 which any configured prefix may have in order to be 431 eligible for testing against the MatchPrefix. 433 MatchPrefix The 128-bit prefix to be compared with each interface's 434 prefix or address. 436 4.2.1.2. Use-Prefix Part 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | UseLen | KeepLen | FlagMask | RAFlags | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Valid Lifetime | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Preferred Lifetime | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |V|P| reserved | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 +- -+ 451 | | 452 +- UsePrefix -+ 453 | | 454 +- -+ 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Fields: 460 UseLen An 8-bit unsigned integer less than or equal to 128 461 specifying the number of initial bits of UsePrefix to 462 use in creating a new prefix for an interface. 464 KeepLen An 8-bit unsigned integer less than or equal to (128- 465 UseLen) specifying the number of bits of the prefix or 466 address which matched the associated Match-Prefix which 467 should be retained in the new prefix. The retained bits 468 are those at positions UseLen through (UseLen+KeepLen-1) 469 in the matched address or prefix, and they are copied to 470 the same positions in the New Prefix. 472 FlagMask An 8-bit mask. A 1 bit in any position means that the 473 corresponding flag bit in a Router Advertisement (RA) 474 Prefix Information Option for the New Prefix should be 475 set from the RAFlags field in this Use-Prefix Part. A 0 476 bit in the FlagMask means that the RA flag bit for the 477 New Prefix should be copied from the corresponding RA 478 flag bit of the Matched Prefix. 480 RAFlags An 8 bit field which, under control of the FlagMask 481 field, may be used to initialize the flags in Router 482 Advertisement Prefix Information Options [ND] which 483 advertise the New Prefix. Note that only two flags have 484 defined meanings to date: the L (on-link) and A 485 (autonomous configuration) flags. These flags occupy 486 the two leftmost bit positions in the RAFlags field, 487 corresponding to their position in the Prefix 488 Information Option. 490 Valid Lifetime 491 A 32-bit unsigned integer which is the number of seconds 492 for which the New Prefix will be valid [ND, SAA]. 494 Preferred Lifetime 495 A 32-bit unsigned integer which is the number of seconds 496 for which the New Prefix will be preferred [ND, SAA]. 498 V A 1-bit flag indicating that the valid lifetime of the 499 New Prefix MUST be effectively decremented in real time. 501 P A 1-bit flag indicating that the preferred lifetime of 502 the New Prefix MUST be effectively decremented in real 503 time. 505 UsePrefix The 128-bit Use-prefix which either becomes or is used 506 in forming (if KeepLen is nonzero) the New Prefix. It 507 MUST NOT have the form of a multicast or link-local 508 address [AARCH]. 510 4.3. Message Body -- Result Message 512 The body of an RR Result message is a sequence of zero or more Match 513 Reports of 24 octets. An RR Command message with the "R" flag set 514 will elicit an RR Result message containing one Match Report for 515 each Prefix Control Operation, for each different prefix it matches 516 on each interface. The Match Report has the following format. 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | reserved |B|F| Ordinal | MatchedLen | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | InterfaceIndex | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | | 526 +- -+ 527 | | 528 +- MatchedPrefix -+ 529 | | 530 +- -+ 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Fields: 536 B A one-bit flag which, when set, indicates that one or 537 more fields in the associated PCO were out of bounds. 538 The bounds check is described in section 5.3. 540 F A one-bit flag which, when set, indicates that one or 541 more Use-Prefix parts from the associated PCO were not 542 honored by the router because of attempted formation of 543 a forbidden prefix format, such as a multicast or 544 loopback address. 546 Ordinal Copied from the Prefix Control Operation whose 547 MatchPrefix matched the MatchedPrefix on the interface 548 indicated by InterfaceIndex. 550 MatchedLen The length of the Matched Prefix. 552 InterfaceIndex 553 The router's numeric designation of the interface on 554 which the MatchedPrefix was configured. This MUST be 555 the same as the value of ipv6IfIndex which designates 556 that index in the SNMP IPv6 MIB General Group [IPV6MIB]. 558 It is possible for a Result message to be larger than the Command 559 message which elicited it. Such a Result message may have to be 560 fragmented for transmission. If so, it SHOULD be fragmented to the 561 IPv6 minimum required MTU [IPV6]. 563 5. Message Processing 565 Processing of received Router Renumbering Result messages is 566 entirely implementation-defined. Implementation of Command message 567 processing may vary in detail from the procedure set forth below, so 568 long as the result is not affected. 570 Processing of received Router Renumbering Command messages consists 571 of three conceptual parts: header check, bounds check, and 572 execution. 574 5.1. Header Check 576 The ICMPv6 checksum and type are presumed to have been checked 577 before a Router Renumbering module receives a Command to process. 578 In an implementation environment where this may not be the case, 579 those checks MUST be made at this point in the processing. 581 If the ICMPv6 length derived from the IPv6 length is less than 16 582 octets, the message MUST be discarded and SHOULD be logged to 583 network management. 585 If the ICMPv6 Code field indicates a Result message, a router which 586 is not a source of RR Command messages MUST discard the message and 587 SHOULD NOT log it to network management. 589 If the IPv6 destination address is neither an All Routers multicast 590 address [AARCH] nor one of the receiving router's unicast addresses, 591 the message MUST be discarded and SHOULD be logged to network 592 management. 594 Next, the SequenceNumber is compared to the Recorded Sequence 595 Number. (If no RR messages have been received and accepted since 596 system initialization, the Recorded Sequence Number is zero.) This 597 comparison is done with the two numbers considered as unsigned 598 integers, not as DNS-style serial numbers. If the SequenceNumber is 599 less than the Recorded Sequence Number, the message MUST be 600 discarded and SHOULD be logged to network management. 602 Finally, if the SequenceNumber in the message is greater than the 603 Recorded Sequence Number or the T flag is set, skip to the bounds 604 check. Otherwise the SegmentNumber MUST now be checked. If a 605 correctly authenticated message with the same SequenceNumber and 606 SegmentNumber has not already been processed, skip to the bounds 607 check. Otherwise, this Command is a duplicate and not a Test 608 Command. If the R flag is not set, the duplicate message MUST be 609 discarded and SHOULD NOT be logged to network management. If R is 610 set, an RR Result message with the P flag set MUST be scheduled for 611 transmission to the source address of the Command after a random 612 time uniformly distributed between 0 and MaxDelay milliseconds. The 613 body of that Result message MUST either be empty or be a saved copy 614 of the Result message body generated by processing of the previous 615 message with the same SequenceNumber and SegmentNumber. After 616 scheduling the Result message, the Command MUST be discarded without 617 further processing. 619 5.2. Bounds Check 621 If the SequenceNumber is greater than the Recorded Sequence Number, 622 then the list of processed SegmentNumbers and the set of saved 623 Result messages, if any, MUST be cleared and the Recorded Sequence 624 Number MUST be updated to the value used in the current message, 625 regardless of subsequent processing errors. 627 Next, if the ICMPv6 Code field indicates a Sequence Number Reset, 628 skip to section 6. 630 At this point, if T is set in the RR header and R is not set, the 631 message MAY be discarded without further processing. 633 If the R flag is set, begin constructing an RR Result message. The 634 RR header of the Result message is completely determined at this 635 time except for the Checksum. 637 The values of the following fields of a PCO MUST be checked to 638 ensure that they are within the appropriate bounds. 640 OpCode must be a defined value. 642 OpLength must be of the form 4N+3 and consistent the the length 643 of the Command packet and the PCO's offset within the 644 packet. 646 MatchLen must be between 0 and 128 inclusive 647 UseLen, KeepLen 648 in each Use-Prefix Part must be between 0 and 128 649 inclusive, as must the sum of the two. 651 If any of these fields are out of range in a PCO, the entire PCO 652 MUST NOT be performed on any interface. If the R flag is set in the 653 RR header then add to the RR Result message a Match Report with the 654 B flag set, the F flag clear, the Ordinal copied from the PCO, and 655 all other fields zero. This Match Report MUST be included only 656 once, not once per interface. 658 Note that MinLen and MaxLen need not be explicitly bounds checked, 659 even though certain combinations of values will make any matches 660 impossible. 662 5.3. Execution 664 For each applicable router interface, as determined by the A and S 665 flags, the Prefix Control Operations in an RR Command message must 666 be carried out in order of appearance. The relative order of PCO 667 processing among different interfaces is not specified. 669 If the T flag is set, create a copy of each interface's 670 configuration on which to operate, because the results of processing 671 a PCO may affect the processing of subsequent PCOs. Note that if 672 all operations are performed on one interface before proceeding to 673 another interface, only one interface-configuration copy will be 674 required at a time. 676 For each interface and for each Prefix Control Operation, each 677 prefix configured on that interface with a length between the MinLen 678 and MaxLen values in the PCO is tested to determine whether it 679 matches (as defined in section 3.1) the MatchPrefix of the PCO. The 680 configured prefixes are tested in an arbitrary order. Any new 681 prefix configured on an interface by the effect of a given PCO MUST 682 NOT be tested against that PCO, but MUST be tested against all 683 subsequent PCOs in the same RR Command message. 685 Under a certain condition the addresses on an interface are also 686 tested to see whether any of them matches the MatchPrefix. If and 687 only if a configured prefix "P" does have a length between MinLen 688 and MaxLen inclusive, does not match the MatchPrefix "M", but M does 689 match P (this can happen only if M is longer than P), then those 690 addresses on that interface which match P MUST be tested to 691 determine whether any of them matches M. If any such address does 692 match M, process the PCO as if P matched M, but when forming New 693 Prefixes, if KeepLen is non-zero, bits are copied from the address. 695 This special case allows a PCO to be easily targeted to a single 696 specific interface in a network. 698 If P does not match M, processing is finished for this combination 699 of PCO, interface and prefix. Continue with another prefix on the 700 same interface if there are any more prefixes which have not been 701 tested against this PCO and were not created by the action of this 702 PCO. If no such prefixes remain on the current interface, continue 703 processing with the next PCO on the same interface, or with another 704 interface. 706 If P does match M, either directly or because a configured address 707 which matches P also matches M, then P is the Matched Prefix. 708 Perform the following steps. 710 If the Command has the R flag set, add a Match Report to 711 the Result message being constructed. 713 If the OpCode is CHANGE, mark P for deletion from the 714 current interface. 716 If the OpCode is SET-GLOBAL, mark all global-scope 717 prefixes on the current interface for deletion. 719 If there are any Use-Prefix parts in the current PCO, form 720 the New Prefixes. Discard any New Prefix which has a 721 forbidden format, and if the R flag is set in the command, 722 set the F flag in the Match Report for this PCO and 723 interface. Forbidden prefix formats include, at a 724 minimum, multicast, unspecified and loopback addresses. 725 [AARCH] Any implementation MAY forbid, or allow the 726 network manager to forbid other formats as well. 728 For each New Prefix which is already configured on the 729 current interface, unmark that prefix for deletion and 730 update the lifetimes and RA flags. For each New Prefix 731 which is not already configured, add the prefix and, if 732 appropriate, configure an address with that prefix. 734 Delete any prefixes which are still marked for deletion, 735 together with any addresses which match those prefixes but 736 do not match any prefix which is not marked for deletion. 738 After processing all the Prefix Control Operations on all 739 the interfaces, an implementation MUST record the 740 SegmentNumber of the packet in a list associated with the 741 SequenceNumber. 743 If the Command has the R flag set, compute the Checksum 744 and schedule the Result message for transmission after a 745 random time uniformly distributed between 0 and MaxDelay 746 milliseconds. A copy of the Result message MAY be saved 747 to be retransmitted in response to a duplicate Command. 749 5.4. Summary of Effects 751 The only Neighbor Discovery [ND] parameters which can be affected by 752 Router Renumbering are the following. 754 A router's addresses and advertised prefixes, including the 755 prefix lengths. 757 The flag bits (L and A, and any which may be defined in the 758 future) and the valid and preferred lifetimes which appear in a 759 Router Advertisement Prefix Information Option. 761 The unnamed property of the lifetimes, which specifies whether 762 they are fixed or decrementing. 764 Other internal router information, such as the time until the next 765 unsolicited Router Advertisement or MIB variables MAY be affected as 766 needed. 768 All configuration changes resulting from Router Renumbering SHOULD 769 be saved to non-volatile storage where this facility exists. The 770 problem of properly restoring prefix lifetimes from non-volatile 771 storage exists independently of Router Renumbering and deserves 772 careful attention, but is outside the scope of this document. 774 6. Sequence Number Reset 776 It may prove necessary in practice to reset a router's Recorded 777 Sequence Number. This is a safe operation only when all 778 cryptographic keys previously used to authenticate RR Commands have 779 expired or been revoked. For this reason, the Sequence Number Reset 780 message is defined to accomplish both functions. 782 When a Sequence Number Reset (SNR) has been authenticated and has 783 passed the header check, the router MUST invalidate all keys which 784 have been used to authenticate previous RR Commands, including the 785 key which authenticated the SNR itself. Then it MUST discard any 786 saved RR Result messages, clear the list of recorded SegmentNumbers 787 and reset the Recorded Sequence Number to zero. 789 The router SHOULD establish one or more new authentication keys for 790 Router Renumbering use. The details of this process will depend on 791 whether manual keying or a key management protocol is used. In 792 either case, if no new keys can be established, no new Commands can 793 be processed. 795 A SNR message SHOULD contain no PCOs, since they will be ignored. 797 Note that the invalidation of authentication keys caused by a valid 798 SNR message will cause retransmitted copies of that message to be 799 ignored. 801 7. IANA Considerations 803 Following the policies outlined in [IANACON], new values of the Code 804 field in the Router Renumbering Header and the OpCode field of the 805 Match-Prefix Part are to be allocated by IETF consensus only. 807 8. Security Considerations 809 The Router Renumbering mechanism proposed here is very powerful and 810 prevention of spoofing it is important. Replay of old messages must 811 be prevented, except in the narrow case of idempotent messages which 812 are still valid. (These are intended to be replayed for 813 reliability's sake.) What constitutes a sufficiently strong 814 authentication algorithm may change from time to time, but 815 algorithms should be chosen which are strong against current key- 816 recovery and forgery attacks. 818 Authentication keys must be as well protected as is any other access 819 method that allows reconfiguration of a site's routers. 820 Distribution of keys must not expose them or permit alteration, and 821 key validity must be limited in terms of time and number of messages 822 authenticated. 824 Note that although a reset of the Recorded Sequence Number requires 825 the cancellation of previously-used authentication keys, 826 introduction of new keys and expiration of old keys does not require 827 resetting the Recorded Sequence Number. 829 8.1. Security Policy and Association Database Entries 831 The Security Policy Database (SPD) [IPSEC] of a router implementing 832 this specification MUST cause incoming Router Renumbering Command 833 packets to either be discarded or have IPsec applied. (The 834 determination of "discard" or "apply" MAY be based on the source 835 address.) The resulting Security Association Database (SAD) entries 836 MUST ensure authentication and integrity of the destination address 837 and the RR Header and Message Body, and the body length implied by 838 the IPv6 length and intervening extension headers. These 839 requirements are met by the use of the Authentication Header [AH] in 840 transport or tunnel mode, or the Encapsulating Security Payload 841 [ESP] in tunnel mode with non-NULL authentication. The mandatory- 842 to-implement IPsec authentication algorithms (other than NULL) seem 843 strong enough for Router Renumbering at the time of this writing. 845 Note that for the SPD to distinguish Router Renumbering from other 846 ICMP packets requires the use of the ICMP Type field as a selector. 847 This is consistent with, although not mentioned by, the Security 848 Architecture specification [IPSEC]. 850 At the time of this writing, there exists no multicast key 851 management protocol for IPsec and none is on the horizon. Manually 852 configured Security Associations will therefore be common. The 853 occurrence of "from traffic" in the table below would therefore more 854 realistically be a wildcard or a fixed range. Use of a small set of 855 shared keys per management station suffices, so long as key 856 distribution and storage are sufficiently safeguarded. 858 A sufficient set of SPD entries for incoming traffic could select 860 Field SPD Entry SAD Entry 861 ------- --------- --------- 862 Source wildcard from traffic 863 Destination wildcard from SPD 864 Transport ICMPv6 from SPD 865 ICMP Type Rtr. Renum. from SPD 866 Action Apply IPsec 867 SA Spec AH/Transport Mode 869 or there might be an entry for each management station and/or for 870 each of the router's unicast addresses and for each of the defined 871 All-Routers multicast addresses, and a final wildcard entry to 872 discard all other incoming RR messages. 874 The SPD and SAD are conceptually per-interface databases. This fact 875 may be exploited to permit shared management of a border router, for 876 example, or to discard all Router Renumbering traffic arriving over 877 tunnels. 879 9. Usage Examples 881 This section sketches some sample applications of Router 882 Renumbering. Extension headers, including required IPsec headers, 883 between the IPv6 header and the ICMPv6 header are not shown in the 884 examples. 886 9.1. Maintaining Global-Scope Prefixes 888 A simple use of the Router Renumbering mechanism, and one which is 889 expected to to be common, is the maintenance of a set of global 890 prefixes with a subnet structure that matches that of the site's 891 site-local address assignments. In the steady state this would 892 serve to keep the Preferred and Valid lifetimes set to their desired 893 values. During a renumbering transition, similar Command messages 894 can add new prefixes and/or delete old ones. An outline of a 895 suitable Command message follows. Fields not listed are presumed 896 set to suitable values. This Command assumes all router interfaces 897 to be maintained already have site-local [AARCH] addresses. 899 IPv6 Header 900 Next Header = 58 (ICMPv6) 901 Source Address = (Management Station) 902 Destination Address = FF05::2 (All Routers, site-local scope) 904 ICMPv6/RR Header 905 Type = 138 (Router Renumbering), Code = 0 (Command) 906 Flags = 60 hex (R, A) 908 First (and only) PCO: 910 Match-Prefix Part 911 OpCode = 3 (SET-GLOBAL) 912 OpLength = 4 N + 3 (assuming N global prefixes) 913 Ordinal = 0 (arbitrary) 914 MatchLen = 10 915 MatchPrefix = FEC0::0 917 First Use-Prefix Part 918 UseLen = 48 (Length of TLA ID + RES + NLA ID [AARCH]) 919 KeepLen = 16 (Length of SLA (subnet) ID [AARCH]) 920 FlagMask, RAFlags, Lifetimes, V & P flags -- as desired 921 UsePrefix = First global /48 prefix 923 . . . 925 Nth Use-Prefix Part 926 UseLen = 48 927 KeepLen = 16 928 FlagMask, RAFlags, Lifetimes, V & P flags -- as desired 929 UsePrefix = Last global /48 prefix 931 This will cause N global prefixes to be set (or updated) on each 932 applicable interface. On each interface, the SLA ID (subnet) field 933 of each global prefix will be copied from the existing site-local 934 prefix. 936 9.2. Renumbering a Subnet 938 A subnet can be gracefully renumbered by setting the valid and 939 preferred timers on the old prefix to a short value and having them 940 run down, while concurrently adding adding the new prefix. Later, 941 the expired prefix is deleted. The first step is described by the 942 following RR Command. 944 IPv6 Header 945 Next Header = 58 (ICMPv6) 946 Source Address = (Management Station) 947 Destination Address = FF05::2 (All Routers, site-local scope) 949 ICMPv6/RR Header 950 Type = 138 (Router Renumbering), Code = 0 (Command) 951 Flags = 60 hex (R, A) 953 First (and only) PCO: 955 Match-Prefix Part 956 OpCode = 2 (CHANGE) 957 OpLength = 11 (reflects 2 Use-Prefix Parts) 958 Ordinal = 0 (arbitrary) 959 MatchLen = 64 960 MatchPrefix = Old /64 prefix 962 First Use-Prefix Part 963 UseLen = 0 964 KeepLen = 64 (this retains the old prefix value intact) 965 FlagMask = 0, RAFlags = 0 966 Valid Lifetime = 28800 seconds (8 hours) 967 Preferred Lifetime = 7200 seconds (2 hours) 968 V flag = 1, P flag = 1 969 UsePrefix = 0::0 971 Second Use-Prefix Part 972 UseLen = 64 973 KeepLen = 0 974 FlagMask = 0, RAFlags = 0 975 Lifetimes, V & P flags -- as desired 976 UsePrefix = New /64 prefix 978 The second step, deletion of the old prefix, can be done by an RR 979 Command with the same Match-Prefix Part (except for an OpLength 980 reduced from 11 to 3) and no Use-Prefix Parts. Any temptation to 981 set KeepLen = 64 in the second Use-Prefix Part above should be 982 resisted, as it would instruct the router to sidestep address 983 configuration. 985 10. Acknowledgments 987 This protocol was designed by Matt Crawford based on an idea of 988 Robert Hinden and Geert Jan de Groot. Many members of the IPNG 989 Working Group contributed useful comments, in particular members of 990 the DIGITAL UNIX IPv6 team. Bill Sommerfeld gave helpful nudges in 991 the IPsec considerations. 993 11. References 995 [AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing 996 Architecture", Currently draft-ietf-ipngwg-addr-arch-v2-07.txt. 998 [AH] S. Kent, R. Atkinson, "IP Authentication Header", Currently 999 draft-ietf-ipsec-auth-header-07.txt. 1001 [ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 1002 (ESP)", Currently draft-ietf-ipsec-esp-v2-06.txt. 1004 [IANACON] T. Narten, H. T. Alvestrand, "Guidelines for Writing an 1005 IANA Considerations Section in RFCs", RFC 2434. 1007 [ICMPV6] A. Conta, S. Deering, "Internet Control Message Protocol 1008 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", currently 1009 draft-ietf-ipngwg-icmp-v2-01.txt. 1011 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the 1012 Internet Protocol", currently draft-ietf-ipsec-arch-sec-07.txt. 1014 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 1015 Specification", currently draft-ietf-ipngwg-ipv6-spec-v2-02.txt. 1017 [IPV6MIB] D. Haskin, S. Onishi, "Management Information Base for IP 1018 Version 6: Textual Conventions and General Group", currently 1020 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 1021 Requirement Levels," RFC 2119. 1023 [ND] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP 1024 Version 6 (IPv6)", currently draft-ietf-ipngwg-discovery-v2- 1025 03.txt. 1027 12. Author's Address 1029 Matt Crawford 1030 Fermilab MS 368 1031 PO Box 500 1032 Batavia, IL 60510 1033 USA 1035 Phone: +1 630 840 3461 1036 Email: crawdad@fnal.gov