idnits 2.17.1 draft-ietf-ipngwg-router-renum-09.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): ---------------------------------------------------------------------------- ** 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 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 651 has weird spacing: '...pLength mus...' == Line 655 has weird spacing: '...atchLen mus...' == Line 878 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 (June 25, 1999) is 9065 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 505, but not defined ** Obsolete normative reference: RFC 2373 (ref. 'AARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'ANM' ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2434 (ref. 'IANACON') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (ref. 'ICMPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) -- Duplicate reference: RFC2460, mentioned in 'IPV6', was also mentioned in 'ICMPV6'. ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2466 (ref. 'IPV6MIB') (Obsoleted by RFC 4293, RFC 8096) ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 1850 (ref. 'OSPFMIB') (Obsoleted by RFC 4750) Summary: 17 errors (**), 0 flaws (~~), 6 warnings (==), 4 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 June 25, 1999 5 Router Renumbering for IPv6 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 1. Abstract 29 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently 30 make initial assignments of address prefixes to hosts. Aside from 31 the problem of connection survival across a renumbering event, these 32 two mechanisms also simplify the reconfiguration of hosts when the 33 set of valid prefixes changes. 35 This document defines a mechanism called Router Renumbering ("RR") 36 which allows address prefixes on routers to be configured and 37 reconfigured almost as easily as the combination of Neighbor 38 Discovery and Address Autoconfiguration works for hosts. It 39 provides a means for a network manager to make updates to the 40 prefixes used by and advertised by IPv6 routers throughout a site. 42 Status of this Memo ............................................... 1 44 1. Abstract ...................................................... 1 46 2. Functional Overview ........................................... 3 48 3. Definitions ................................................... 4 49 3.1. Terminology ............................................. 4 50 3.2. Requirements ............................................ 5 52 4. Message Format ................................................ 5 53 4.1. Router Renumbering Header ............................... 7 54 4.2. Message Body -- Command Message ......................... 9 55 4.2.1. Prefix Control Operation .......................... 9 56 4.2.1.1. Match-Prefix Part ........................... 9 57 4.2.1.2. Use-Prefix Part ............................. 11 58 4.3. Message Body -- Result Message .......................... 12 60 5. Message Processing ............................................ 14 61 5.1. Header Check ............................................ 14 62 5.2. Bounds Check ............................................ 15 63 5.3. Execution ............................................... 16 64 5.4. Summary of Effects ...................................... 18 66 6. Sequence Number Reset ......................................... 18 68 7. IANA Considerations ........................................... 19 70 8. Security Considerations ....................................... 19 71 8.1. Security Policy and Association Database Entries ........ 19 73 9. Implementation and Usage Advice for Reliability ............... 20 74 9.1. Outline and Definitions ................................. 21 75 9.2. Computations ............................................ 23 76 9.3. Additional Assurance Methods ............................ 25 78 10. Usage Examples ............................................... 25 79 10.1. Maintaining Global-Scope Prefixes ...................... 25 80 10.2. Renumbering a Subnet ................................... 26 82 11. Acknowledgments .............................................. 28 84 12. References ................................................... 28 86 13. Author's Address ............................................. 29 88 Appendix -- Derivation of Reliability Estimates ................... 30 89 2. Functional Overview 91 Router Renumbering Command packets contain a sequence of Prefix 92 Control Operations (PCOs). Each PCO specifies an operation, a 93 Match-Prefix, and zero or more Use-Prefixes. A router processes 94 each PCO in sequence, checking each of its interfaces for an address 95 or prefix which matches the Match-Prefix. For every interface on 96 which a match is found, the operation is applied. The operation is 97 one of ADD, CHANGE, or SET-GLOBAL to instruct the router to 98 respectively add the Use-Prefixes to the set of configured prefixes, 99 remove the prefix which matched the Match-Prefix and replace it with 100 the Use-Prefixes, or replace all global-scope prefixes with the 101 Use-Prefixes. If the set of Use-Prefixes in the PCO is empty, the 102 ADD operation does nothing and the other two reduce to deletions. 104 Additional information for each Use-Prefix is included in the Prefix 105 Control Operation: the valid and preferred lifetimes to be included 106 in Router Advertisement Prefix Information Options [ND], and either 107 the L and A flags for the same option, or an indication that they 108 are to be copied from the prefix that matched the Match-Prefix. 110 It is possible to instruct routers to create new prefixes by 111 combining the Use-Prefixes in a PCO with some portion of the 112 existing prefix which matched the Match-Prefix. This simplifies 113 certain operations which are expected to be among the most common. 114 For every Use-Prefix, the PCO specifies a number of bits which 115 should be copied from the existing address or prefix which matched 116 the Match-Prefix and appended to the use-prefix prior to configuring 117 the new prefix on the interface. The copied bits are zero or more 118 bits from the positions immediately after the length of the Use- 119 Prefix. If subnetting information is in the same portion of the old 120 and new prefixes, this synthesis allows a single Prefix Control 121 Operation to define a new global prefix on every router in a site, 122 while preserving the subnetting structure. 124 Because of the power of the Router Renumbering mechanism, each RR 125 message includes a sequence number to guard against replays, and is 126 required to be authenticated and integrity-checked. Each single 127 Prefix Control Operation is idempotent and so could be retransmitted 128 for improved reliability, as long as the sequence number is current, 129 without concern about multiple processing. However, non-idempotent 130 combinations of PCOs can easily be constructed and messages 131 containing such combinations could not be safely reprocessed. 132 Therefore, all routers are required to guard against processing an 133 RR message more than once. To allow reliable verification that 134 Commands have been received and processed by routers, a mechanism 135 for duplicate-command notification to the management station is 136 included. 138 Possibly a network manager will want to perform more renumbering, or 139 exercise more detailed control, than can be expressed in a single 140 Router Renumbering packet on the available media. The RR mechanism 141 is most powerful when RR packets are multicast, so IP fragmentation 142 is undesirable. For these reasons, each RR packet contains a 143 "Segment Number". All RR packets which have a Sequence Number 144 greater than or equal to the highest value seen are valid and must 145 be processed. However, a router must keep track of the Segment 146 Numbers of RR messages already processed and avoid reprocessing a 147 message whose Sequence Number and Segment Number match a previously 148 processed message. (This list of processed segment numbers is reset 149 when a new highest Sequence Number is seen.) 151 The Segment Number does not impose an ordering on packet processing. 152 If a specific sequence of operations is desired, it may be achieved 153 by ordering the PCOs in a single RR Command message or through the 154 Sequence Number field. 156 There is a "Test" flag which indicates that all routers should 157 simulate processing of the RR message and not perform any actual 158 reconfiguration. A separate "Report" flag instructs routers to send 159 a Router Renumbering Result message back to the source of the RR 160 Command message indicating the actual or simulated result of the 161 operations in the RR Command message. 163 The effect or simulated effect of an RR Command message may also be 164 reported to network management by means outside the scope of this 165 document, regardless of the value of the "Report" flag. 167 3. Definitions 169 3.1. Terminology 171 Address 172 This term always refers to a 128-bit IPv6 address [AARCH]. When 173 referring to bits within an address, they are numbered from 0 to 174 127, with bit 0 being the first bit of the Format Prefix. 176 Prefix 177 A prefix can be understood as an address plus a length, the 178 latter being an integer in the range 0 to 128 indicating how many 179 leading bits are significant. When referring to bits within a 180 prefix, they are numbered in the same way as the bits of an 181 address. For example, the significant bits of a prefix whose 182 length is L are the bits numbered 0 through L-1, inclusive. 184 Match 185 An address A "matches" a prefix P whose length is L if the first 186 L bits of A are identical with the first L bits of P. (Every 187 address matches a prefix of length 0.) A prefix P1 with length 188 L1 matches a prefix P2 of length L2 if L1 >= L2 and the first L2 189 bits of P1 and P2 are identical. 191 Prefix Control Operation 192 This is the smallest individual unit of Router Renumbering 193 operation. A Router Renumbering Command packet includes zero or 194 more of these, each comprising one matching condition, called a 195 Match-Prefix Part, and zero or more substitution specifications, 196 called Use-Prefix Parts. 198 Match-Prefix 199 This is a Prefix against which a router compares the addresses 200 and prefixes configured on its interfaces. 202 Use-Prefix 203 The prefix and associated information which is to be configured 204 on a router interface when certain conditions are met. 206 Matched Prefix 207 The existing prefix or address which matched a Match-Prefix. 209 New Prefix 210 A prefix constructed from a Use-Prefix, possibly including some 211 of the Matched Prefix. 213 Recorded Sequence Number 214 The highest sequence number found in a valid message MUST be 215 recorded in non-volatile storage. 217 Note that "matches" is a transitive relation but not symmetric. 218 If two prefixes match each other, they are identical. 220 3.2. Requirements 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [KWORD]. 226 4. Message Format 228 There are two types of Router Renumbering messages: Commands, which 229 are sent to routers, and Results, which are sent by routers. A 230 third message type is used to synchronize a reset of the Recorded 231 Sequence Number with the cancellation of cryptographic keys. The 232 three types of messages are distinguished the ICMPv6 "Code" field 233 and differ in the contents of the "Message Body" field. 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 / IPv6 header, extension headers / 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 / ICMPv6 & RR Header (16 octets) / 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 / RR Message Body / 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Router Renumbering Message Format 251 Router Renumbering messages are carried in ICMPv6 packets with 252 Type = 138. The RR message comprises an RR Header, containing the 253 ICMPv6 header, the sequence and segment numbers and other 254 information, and the RR Message Body, of variable length. 256 All fields marked "reserved" or "res" MUST be set to zero on 257 generation of an RR message, and ignored on receipt. 259 All implementations which generate Router Renumbering Command 260 messages MUST support sending them to the All Routers multicast 261 address with link and site scopes, and to unicast addresses of 262 link-local and site-local formats. All routers MUST be capable of 263 receiving RR Commands sent to those multicast addresses and to any 264 of their link local and site local unicast addresses. 265 Implementations SHOULD support sending and receiving RR messages 266 addressed to other unicast addresses. An implementation which is 267 both a sender and receiver of RR commands SHOULD support use of the 268 All Routers multicast address with node scope. 270 Data authentication and message integrity MUST be provided for all 271 Router Renumbering Command messages by appropriate IP Security 272 [IPSEC] means. The integrity assurance must include the IPv6 273 destination address and the RR Header and Message Body. See section 274 8, "Security Considerations". 276 The use of authentication for Router Renumbering Result messages is 277 RECOMMENDED. 279 4.1. Router Renumbering Header 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Code | Checksum | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | SequenceNumber | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | SegmentNumber | Flags | MaxDelay | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | reserved | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Fields: 295 Type 138 (decimal), the ICMPv6 type value assigned to Router 296 Renumbering 298 Code 0 for a Router Renumbering Command 299 1 for a Router Renumbering Result 300 255 for a Sequence Number Reset. 301 The Sequence Number Reset is described in section 6. 303 Checksum The ICMPv6 checksum, as specified in [ICMPV6]. The 304 checksum covers the IPv6 pseudo-header and all fields of 305 the RR message from the Type field onward. 307 SequenceNumber 308 An unsigned 32-bit sequence number. The sequence number 309 MUST be non-decreasing between Sequence Number Resets. 311 SegmentNumber 312 An unsigned 8-bit field which enumerates different valid 313 RR messages having the same SequenceNumber. No ordering 314 among RR messages is imposed by the SegmentNumber. 316 Flags A combination of one-bit flags. Five are defined and 317 three bits are reserved. 319 +-+-+-+-+-+-+-+-+ 320 |T|R|A|S|P| res | 321 +-+-+-+-+-+-+-+-+ 323 The flags T, R, A and S have defined meanings in an RR 324 Command message. In a Result message they MUST be 325 copied from the corresponding Command. The P flag is 326 meaningful only in a Result message and MUST be zero in 327 a transmitted Command and ignored in a received Command. 329 T Test command -- 330 0 indicates that the router configuration is to be 331 modified; 332 1 indicates a "Test" message: processing is to be 333 simulated and no configuration changes are to be 334 made. 336 R Result requested -- 337 0 indicates that a Result message MUST NOT be sent 338 (but other forms of logging are not precluded); 339 1 indicates that the router MUST send a Result 340 message upon completion of processing the Command 341 message; 343 A All interfaces -- 344 0 indicates that the Command MUST NOT be applied to 345 interfaces which are administratively shut down; 346 1 indicates that the Command MUST be applied to all 347 interfaces regardless of administrative shutdown 348 status. 350 S Site-specific -- This flag MUST be ignored unless 351 the router treats interfaces as belonging to 352 different "sites". 353 0 indicates that the Command MUST be applied to 354 interfaces regardless of which site they belong 355 to; 356 1 indicates that the Command MUST be applied only to 357 interfaces which belong to the same site as the 358 interface to which the Command is addressed. If 359 the destination address is appropriate for 360 interfaces belonging to more than one site, then 361 the Command MUST be applied only to interfaces 362 belonging to the same site as the interface on 363 which the Command was received. 365 P Processed previously -- 366 0 indicates that the Result message contains the 367 complete report of processing the Command; 368 1 indicates that the Command message was previously 369 processed (and is not a Test) and the responding 370 router is not processing it again. This Result 371 message MAY have an empty body. 373 MaxDelay An unsigned 16-bit field specifying the maximum time, in 374 milliseconds, by which a router MUST delay sending any 375 reply to this Command. Implementations MAY generate the 376 random delay between 0 and MaxDelay milliseconds with a 377 finer granularity than 1ms. 379 4.2. Message Body -- Command Message 381 The body of an RR Command message is a sequence of zero or more 382 Prefix Control Operations, each of variable length. The end of the 383 sequence MAY be inferred from the IPv6 length and the lengths of 384 extension headers which precede the ICMPv6 header. 386 4.2.1. Prefix Control Operation 388 A Prefix Control Operation has one Match-Prefix Part of 24 octets, 389 followed by zero or more Use-Prefix Parts of 32 octets each. 391 4.2.1.1. Match-Prefix Part 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | OpCode | OpLength | Ordinal | MatchLen | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | MinLen | MaxLen | reserved | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 +- -+ 402 | | 403 +- MatchPrefix -+ 404 | | 405 +- -+ 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Fields: 411 OpCode An unsigned 8-bit field specifying the operation to be 412 performed when the associated MatchPrefix matches an 413 interface's prefix or address. Values are: 415 1 the ADD operation 417 2 the CHANGE operation 419 3 the SET-GLOBAL operation 421 OpLength The total length of this Prefix Control Operation, in 422 units of 8 octets. A valid OpLength will always be of 423 the form 4N+3, with N equal to the number of UsePrefix 424 parts (possibly zero). 426 Ordinal An 8-bit field which MUST have a different value in each 427 Prefix Control Operation contained in a given RR Command 428 message. The value is otherwise unconstrained. 430 MatchLen An 8-bit unsigned integer between 0 and 128 inclusive 431 specifying the number of initial bits of MatchPrefix 432 which are significant in matching. 434 MinLen An 8-bit unsigned integer specifying the minimum length 435 which any configured prefix must have in order to be 436 eligible for testing against the MatchPrefix. 438 MaxLen An 8-bit unsigned integer specifying the maximum length 439 which any configured prefix may have in order to be 440 eligible for testing against the MatchPrefix. 442 MatchPrefix The 128-bit prefix to be compared with each interface's 443 prefix or address. 445 4.2.1.2. Use-Prefix Part 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | UseLen | KeepLen | FlagMask | RAFlags | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Valid Lifetime | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Preferred Lifetime | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |V|P| reserved | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | | 459 +- -+ 460 | | 461 +- UsePrefix -+ 462 | | 463 +- -+ 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Fields: 469 UseLen An 8-bit unsigned integer less than or equal to 128 470 specifying the number of initial bits of UsePrefix to 471 use in creating a new prefix for an interface. 473 KeepLen An 8-bit unsigned integer less than or equal to (128- 474 UseLen) specifying the number of bits of the prefix or 475 address which matched the associated Match-Prefix which 476 should be retained in the new prefix. The retained bits 477 are those at positions UseLen through (UseLen+KeepLen-1) 478 in the matched address or prefix, and they are copied to 479 the same positions in the New Prefix. 481 FlagMask An 8-bit mask. A 1 bit in any position means that the 482 corresponding flag bit in a Router Advertisement (RA) 483 Prefix Information Option for the New Prefix should be 484 set from the RAFlags field in this Use-Prefix Part. A 0 485 bit in the FlagMask means that the RA flag bit for the 486 New Prefix should be copied from the corresponding RA 487 flag bit of the Matched Prefix. 489 RAFlags An 8 bit field which, under control of the FlagMask 490 field, may be used to initialize the flags in Router 491 Advertisement Prefix Information Options [ND] which 492 advertise the New Prefix. Note that only two flags have 493 defined meanings to date: the L (on-link) and A 494 (autonomous configuration) flags. These flags occupy 495 the two leftmost bit positions in the RAFlags field, 496 corresponding to their position in the Prefix 497 Information Option. 499 Valid Lifetime 500 A 32-bit unsigned integer which is the number of seconds 501 for which the New Prefix will be valid [ND, SAA]. 503 Preferred Lifetime 504 A 32-bit unsigned integer which is the number of seconds 505 for which the New Prefix will be preferred [ND, SAA]. 507 V A 1-bit flag indicating that the valid lifetime of the 508 New Prefix MUST be effectively decremented in real time. 510 P A 1-bit flag indicating that the preferred lifetime of 511 the New Prefix MUST be effectively decremented in real 512 time. 514 UsePrefix The 128-bit Use-prefix which either becomes or is used 515 in forming (if KeepLen is nonzero) the New Prefix. It 516 MUST NOT have the form of a multicast or link-local 517 address [AARCH]. 519 4.3. Message Body -- Result Message 521 The body of an RR Result message is a sequence of zero or more Match 522 Reports of 24 octets. An RR Command message with the "R" flag set 523 will elicit an RR Result message containing one Match Report for 524 each Prefix Control Operation, for each different prefix it matches 525 on each interface. The Match Report has the following format. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | reserved |B|F| Ordinal | MatchedLen | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | InterfaceIndex | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | | 535 +- -+ 536 | | 537 +- MatchedPrefix -+ 538 | | 539 +- -+ 540 | | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Fields: 545 B A one-bit flag which, when set, indicates that one or 546 more fields in the associated PCO were out of bounds. 547 The bounds check is described in section 5.3. 549 F A one-bit flag which, when set, indicates that one or 550 more Use-Prefix parts from the associated PCO were not 551 honored by the router because of attempted formation of 552 a forbidden prefix format, such as a multicast or 553 loopback address. 555 Ordinal Copied from the Prefix Control Operation whose 556 MatchPrefix matched the MatchedPrefix on the interface 557 indicated by InterfaceIndex. 559 MatchedLen The length of the Matched Prefix. 561 InterfaceIndex 562 The router's numeric designation of the interface on 563 which the MatchedPrefix was configured. This MUST be 564 the same as the value of ipv6IfIndex which designates 565 that index in the SNMP IPv6 MIB General Group [IPV6MIB]. 567 It is possible for a Result message to be larger than the Command 568 message which elicited it. Such a Result message may have to be 569 fragmented for transmission. If so, it SHOULD be fragmented to the 570 IPv6 minimum required MTU [IPV6]. 572 5. Message Processing 574 Processing of received Router Renumbering Result messages is 575 entirely implementation-defined. Implementation of Command message 576 processing may vary in detail from the procedure set forth below, so 577 long as the result is not affected. 579 Processing of received Router Renumbering Command messages consists 580 of three conceptual parts: header check, bounds check, and 581 execution. 583 5.1. Header Check 585 The ICMPv6 checksum and type are presumed to have been checked 586 before a Router Renumbering module receives a Command to process. 587 In an implementation environment where this may not be the case, 588 those checks MUST be made at this point in the processing. 590 If the ICMPv6 length derived from the IPv6 length is less than 16 591 octets, the message MUST be discarded and SHOULD be logged to 592 network management. 594 If the ICMPv6 Code field indicates a Result message, a router which 595 is not a source of RR Command messages MUST discard the message and 596 SHOULD NOT log it to network management. 598 If the IPv6 destination address is neither an All Routers multicast 599 address [AARCH] nor one of the receiving router's unicast addresses, 600 the message MUST be discarded and SHOULD be logged to network 601 management. 603 Next, the SequenceNumber is compared to the Recorded Sequence 604 Number. (If no RR messages have been received and accepted since 605 system initialization, the Recorded Sequence Number is zero.) This 606 comparison is done with the two numbers considered as unsigned 607 integers, not as DNS-style serial numbers. If the SequenceNumber is 608 less than the Recorded Sequence Number, the message MUST be 609 discarded and SHOULD be logged to network management. 611 Finally, if the SequenceNumber in the message is greater than the 612 Recorded Sequence Number or the T flag is set, skip to the bounds 613 check. Otherwise the SegmentNumber MUST now be checked. If a 614 correctly authenticated message with the same SequenceNumber and 615 SegmentNumber has not already been processed, skip to the bounds 616 check. Otherwise, this Command is a duplicate and not a Test 617 Command. If the R flag is not set, the duplicate message MUST be 618 discarded and SHOULD NOT be logged to network management. If R is 619 set, an RR Result message with the P flag set MUST be scheduled for 620 transmission to the source address of the Command after a random 621 time uniformly distributed between 0 and MaxDelay milliseconds. The 622 body of that Result message MUST either be empty or be a saved copy 623 of the Result message body generated by processing of the previous 624 message with the same SequenceNumber and SegmentNumber. After 625 scheduling the Result message, the Command MUST be discarded without 626 further processing. 628 5.2. Bounds Check 630 If the SequenceNumber is greater than the Recorded Sequence Number, 631 then the list of processed SegmentNumbers and the set of saved 632 Result messages, if any, MUST be cleared and the Recorded Sequence 633 Number MUST be updated to the value used in the current message, 634 regardless of subsequent processing errors. 636 Next, if the ICMPv6 Code field indicates a Sequence Number Reset, 637 skip to section 6. 639 At this point, if T is set in the RR header and R is not set, the 640 message MAY be discarded without further processing. 642 If the R flag is set, begin constructing an RR Result message. The 643 RR header of the Result message is completely determined at this 644 time except for the Checksum. 646 The values of the following fields of a PCO MUST be checked to 647 ensure that they are within the appropriate bounds. 649 OpCode must be a defined value. 651 OpLength must be of the form 4N+3 and consistent the the length 652 of the Command packet and the PCO's offset within the 653 packet. 655 MatchLen must be between 0 and 128 inclusive 657 UseLen, KeepLen 658 in each Use-Prefix Part must be between 0 and 128 659 inclusive, as must the sum of the two. 661 If any of these fields are out of range in a PCO, the entire PCO 662 MUST NOT be performed on any interface. If the R flag is set in the 663 RR header then add to the RR Result message a Match Report with the 664 B flag set, the F flag clear, the Ordinal copied from the PCO, and 665 all other fields zero. This Match Report MUST be included only 666 once, not once per interface. 668 Note that MinLen and MaxLen need not be explicitly bounds checked, 669 even though certain combinations of values will make any matches 670 impossible. 672 5.3. Execution 674 For each applicable router interface, as determined by the A and S 675 flags, the Prefix Control Operations in an RR Command message must 676 be carried out in order of appearance. The relative order of PCO 677 processing among different interfaces is not specified. 679 If the T flag is set, create a copy of each interface's 680 configuration on which to operate, because the results of processing 681 a PCO may affect the processing of subsequent PCOs. Note that if 682 all operations are performed on one interface before proceeding to 683 another interface, only one interface-configuration copy will be 684 required at a time. 686 For each interface and for each Prefix Control Operation, each 687 prefix configured on that interface with a length between the MinLen 688 and MaxLen values in the PCO is tested to determine whether it 689 matches (as defined in section 3.1) the MatchPrefix of the PCO. The 690 configured prefixes are tested in an arbitrary order. Any new 691 prefix configured on an interface by the effect of a given PCO MUST 692 NOT be tested against that PCO, but MUST be tested against all 693 subsequent PCOs in the same RR Command message. 695 Under a certain condition the addresses on an interface are also 696 tested to see whether any of them matches the MatchPrefix. If and 697 only if a configured prefix "P" does have a length between MinLen 698 and MaxLen inclusive, does not match the MatchPrefix "M", but M does 699 match P (this can happen only if M is longer than P), then those 700 addresses on that interface which match P MUST be tested to 701 determine whether any of them matches M. If any such address does 702 match M, process the PCO as if P matched M, but when forming New 703 Prefixes, if KeepLen is non-zero, bits are copied from the address. 704 This special case allows a PCO to be easily targeted to a single 705 specific interface in a network. 707 If P does not match M, processing is finished for this combination 708 of PCO, interface and prefix. Continue with another prefix on the 709 same interface if there are any more prefixes which have not been 710 tested against this PCO and were not created by the action of this 711 PCO. If no such prefixes remain on the current interface, continue 712 processing with the next PCO on the same interface, or with another 713 interface. 715 If P does match M, either directly or because a configured address 716 which matches P also matches M, then P is the Matched Prefix. 717 Perform the following steps. 719 If the Command has the R flag set, add a Match Report to 720 the Result message being constructed. 722 If the OpCode is CHANGE, mark P for deletion from the 723 current interface. 725 If the OpCode is SET-GLOBAL, mark all global-scope 726 prefixes on the current interface for deletion. 728 If there are any Use-Prefix parts in the current PCO, form 729 the New Prefixes. Discard any New Prefix which has a 730 forbidden format, and if the R flag is set in the command, 731 set the F flag in the Match Report for this PCO and 732 interface. Forbidden prefix formats include, at a 733 minimum, multicast, unspecified and loopback addresses. 734 [AARCH] Any implementation MAY forbid, or allow the 735 network manager to forbid other formats as well. 737 For each New Prefix which is already configured on the 738 current interface, unmark that prefix for deletion and 739 update the lifetimes and RA flags. For each New Prefix 740 which is not already configured, add the prefix and, if 741 appropriate, configure an address with that prefix. 743 Delete any prefixes which are still marked for deletion, 744 together with any addresses which match those prefixes but 745 do not match any prefix which is not marked for deletion. 747 After processing all the Prefix Control Operations on all 748 the interfaces, an implementation MUST record the 749 SegmentNumber of the packet in a list associated with the 750 SequenceNumber. 752 If the Command has the R flag set, compute the Checksum 753 and schedule the Result message for transmission after a 754 random time interval uniformly distributed between 0 and 755 MaxDelay milliseconds. This interval SHOULD begin at the 756 conclusion of processing, not the beginning. A copy of 757 the Result message MAY be saved to be retransmitted in 758 response to a duplicate Command. 760 5.4. Summary of Effects 762 The only Neighbor Discovery [ND] parameters which can be affected by 763 Router Renumbering are the following. 765 A router's addresses and advertised prefixes, including the 766 prefix lengths. 768 The flag bits (L and A, and any which may be defined in the 769 future) and the valid and preferred lifetimes which appear in a 770 Router Advertisement Prefix Information Option. 772 That unnamed property of the lifetimes which specifies whether 773 they are fixed values or decrementing in real time. 775 Other internal router information, such as the time until the next 776 unsolicited Router Advertisement or MIB variables MAY be affected as 777 needed. 779 All configuration changes resulting from Router Renumbering SHOULD 780 be saved to non-volatile storage where this facility exists. The 781 problem of properly restoring prefix lifetimes from non-volatile 782 storage exists independently of Router Renumbering and deserves 783 careful attention, but is outside the scope of this document. 785 6. Sequence Number Reset 787 It may prove necessary in practice to reset a router's Recorded 788 Sequence Number. This is a safe operation only when all 789 cryptographic keys previously used to authenticate RR Commands have 790 expired or been revoked. For this reason, the Sequence Number Reset 791 message is defined to accomplish both functions. 793 When a Sequence Number Reset (SNR) has been authenticated and has 794 passed the header check, the router MUST invalidate all keys which 795 have been used to authenticate previous RR Commands, including the 796 key which authenticated the SNR itself. Then it MUST discard any 797 saved RR Result messages, clear the list of recorded SegmentNumbers 798 and reset the Recorded Sequence Number to zero. 800 If the router has no other, unused authentication keys already 801 available for Router Renumbering use it SHOULD establish one or more 802 new valid keys. The details of this process will depend on whether 803 manual keying or a key management protocol is used. In either case, 804 if no keys are available, no new Commands can be processed. 806 A SNR message SHOULD contain no PCOs, since they will be ignored. 808 If and only if the R flag is set in the SNR message, a router MUST 809 respond with a Result Message containing no Match Reports. The 810 header and transmission of the Result are as described in section 5. 812 The invalidation of authentication keys caused by a valid SNR 813 message will cause retransmitted copies of that message to be 814 ignored. 816 7. IANA Considerations 818 Following the policies outlined in [IANACON], new values of the Code 819 field in the Router Renumbering Header (section 4.1) and the OpCode 820 field of the Match-Prefix Part (section 4.2.1.1) are to be allocated 821 by IETF consensus only. 823 8. Security Considerations 825 The Router Renumbering mechanism proposed here is very powerful and 826 prevention of spoofing it is important. Replay of old messages 827 must, in general, be prevented (even though a narrow class of 828 messages exists for which replay would be harmless). What 829 constitutes a sufficiently strong authentication algorithm may 830 change from time to time, but algorithms should be chosen which are 831 strong against current key-recovery and forgery attacks. 833 Authentication keys must be as well protected as any other access 834 method that allows reconfiguration of a site's routers. 835 Distribution of keys must not expose them or permit alteration, and 836 key validity must be limited in terms of time and number of messages 837 authenticated. 839 Note that although a reset of the Recorded Sequence Number requires 840 the cancellation of previously-used authentication keys, 841 introduction of new keys and expiration of old keys does not require 842 resetting the Recorded Sequence Number. 844 8.1. Security Policy and Association Database Entries 846 The Security Policy Database (SPD) [IPSEC] of a router implementing 847 this specification MUST cause incoming Router Renumbering Command 848 packets to either be discarded or have IPsec applied. (The 849 determination of "discard" or "apply" MAY be based on the source 850 address.) The resulting Security Association Database (SAD) entries 851 MUST ensure authentication and integrity of the destination address 852 and the RR Header and Message Body, and the body length implied by 853 the IPv6 length and intervening extension headers. These 854 requirements are met by the use of the Authentication Header [AH] in 855 transport or tunnel mode, or the Encapsulating Security Payload 856 [ESP] in tunnel mode with non-NULL authentication. The mandatory- 857 to-implement IPsec authentication algorithms (other than NULL) seem 858 strong enough for Router Renumbering at the time of this writing. 860 Note that for the SPD to distinguish Router Renumbering from other 861 ICMP packets requires the use of the ICMP Type field as a selector. 862 This is consistent with, although not mentioned by, the Security 863 Architecture specification [IPSEC]. 865 At the time of this writing, there exists no multicast key 866 management protocol for IPsec and none is on the horizon. Manually 867 configured Security Associations will therefore be common. The 868 occurrence of "from traffic" in the table below would therefore more 869 realistically be a wildcard or a fixed range. Use of a small set of 870 shared keys per management station suffices, so long as key 871 distribution and storage are sufficiently safeguarded. 873 A sufficient set of SPD entries for incoming traffic could select 875 Field SPD Entry SAD Entry 876 ------- --------- --------- 877 Source wildcard from traffic 878 Destination wildcard from SPD 879 Transport ICMPv6 from SPD 880 ICMP Type Rtr. Renum. from SPD 881 Action Apply IPsec 882 SA Spec AH/Transport Mode 884 or there might be an entry for each management station and/or for 885 each of the router's unicast addresses and for each of the defined 886 All-Routers multicast addresses, and a final wildcard entry to 887 discard all other incoming RR messages. 889 The SPD and SAD are conceptually per-interface databases. This fact 890 may be exploited to permit shared management of a border router, for 891 example, or to discard all Router Renumbering traffic arriving over 892 tunnels. 894 9. Implementation and Usage Advice for Reliability 896 Users of Router Renumbering will want to be sure that every non- 897 trivial message reaches every intended router. Well-considered 898 exploitation of Router Renumbering's retransmission and response- 899 directing features should make that goal achievable with high 900 confidence in a modestly reliable network. 902 In one set of cases, probably the majority, the network management 903 station will know the complete set of routers under its control. 904 Commands can be retransmitted, with the "R" (Reply-requested) flag 905 set in the RR header, until Results have been collected from all 906 routers. If unicast Security Associations (or the means for 907 creating them) are available, the management station may switch from 908 multicast to unicast transmission when the number of routers still 909 unheard-from is suitably small. 911 To maintain a list of managed routers, the management station can 912 employ any of several automatic methods which may be more convenient 913 than manual entry in a large network. Multicast RR "Test" commands 914 can be sent periodically and the results archived, or the management 915 station can use SNMP to "peek" into a link-state routing protocol 916 such as OSPF [OSPFMIB]. (In the case of OSPF, roughly one router 917 per area would need to be examined to build a complete list of 918 routers.) 920 In a large dynamic network where the set of managed routers is not 921 known but reliable execution is desired, a scalable method for 922 achieving confidence in delivery is described here. Nothing in this 923 section affects the format or content of Router Renumbering 924 messages, nor their processing by routers. 926 A management station implementing these reliability mechanisms MUST 927 alert an operator who attempts to commence a set of Router 928 Renumbering Commands when retransmission of a previous set is not 929 yet completed, but SHOULD allow the operator to override the 930 warning. 932 9.1. Outline and Definitions 934 The set of routers being managed with Router Renumbering is 935 considered as a set of populations, each population having a 936 characteristic probability of successful round-trip delivery of a 937 Command/Result pair. The goal is to estimate a lower bound, P, on 938 the round-trip probability for the whole set. With this estimate 939 and other data about the responses to retransmissions of the 940 Command, a confidence level can be computed for hypothesis that all 941 routers have been heard from. 943 If the true probability of successful round-trip communication with 944 a managed router were a constant, p, for all managed routers then an 945 estimate P of p could be derived from either of these statistics: 947 The expected ratio of the number of routers first heard 948 from after transmission (N + 1) to the number first heard 949 from after N is (1 - p). 951 When N different routers have been heard from after M 952 transmissions of a Command, the expected total number of 953 Result messages received is pNM. If R is the number of 954 Results actually received, then P = R/MN. 956 The two methods are not equivalent. The first suffers numerical 957 problems when the number of routers still to be heard from gets 958 small, so the P = R/MN estimate should be used. 960 Since the round-trip probability is not expected to be uniform in 961 the real world, and the less-reliable units are more important to a 962 lower-bound estimate but more likely to be missed in sampling, the 963 sample from which P is computed is biased toward the less-reliable 964 routers. After the Nth transmission interval, N > 2, neglect all 965 routers heard from in intervals 1 through F from the reliability 966 estimate, where F is the greatest integer less than one-half of N. 967 For example, after five intervals, only routers first heard from in 968 the third through fifth intervals will be counted. 970 A management station implementing the methods of this section should 971 allow the user to specify the following parameters, and default them 972 to the indicated values. 974 Ct The target delivery confidence, default 0.999. 976 Pp A presumptive, pessimistic initial estimate of the lower 977 bound of the round-trip probability, P, to prevent early 978 termination. (See below.) Default 0.75. 980 Ti The initial time between Command retransmissions. Default 4 981 seconds. MaxDelay milliseconds (see section 4.1) must be 982 added to the retransmission timer. Knowledge of the 983 routers' processing time for RR Commands may influence the 984 setting of Ti. Ti+MaxDelay is also the minimum time the 985 management must wait for Results after each transmission 986 before computing a new confidence level. The phrase "end of 987 the Nth interval" means a time Ti+MaxDelay after the Nth 988 transmission of a Command. 990 Tu The upper bound on the period between Command 991 retransmissions. Default 512 seconds. 993 The following variables, some a function of the retransmission 994 counter N, are used in the next section. 996 T(N) The time between Command transmissions N and N+1 is V*T(N) + 997 MaxDelay, where V is random and roughly uniform in the range 998 [0.75, 1.0]. T(1) = Ti and for N > 1, T(N) = min(2*T(N-1), 999 Tu). 1001 M(N) The cumulative number of distinct routers from which replies 1002 have been received to any of the first N transmissions of 1003 the Command. 1005 F=F(N) FLOOR((N-1)/2). All routers from which responses were 1006 received in the first F intervals will be effectively 1007 omitted from the estimate of the round-trip probability 1008 computed at the Nth interval. 1010 R(N,F) The total number of RR Result messages, including 1011 duplicates, received by the end of the Nth interval from 1012 those routers which were NOT heard from in any of the first 1013 F intervals. 1015 p(N) The estimate of the worst-case round-trip delivery 1016 probability. 1018 c(N) The computed confidence level. 1020 An asterisk (*) is used to denote multiplication and a caret (^) 1021 denotes exponentiation. 1023 If the difference in reliability between the "good" and "bad" parts 1024 of a managed network is very great, early c(N) values will be too 1025 high. Retransmissions should continue for at least Nmin = log(1- 1026 Ct)/log(1-Pp) intervals, regardless of the current confidence 1027 estimate. (In fact, there's no need to compute p(N) and c(N) until 1028 after Nmin intervals.) 1030 9.2. Computations 1032 Letting A = N*(M(N)-M(F))/R(N,F) for brevity, the estimate of the 1033 round-trip delivery probability is p(N) = 1-Q, where Q is that root 1034 of the equation 1036 Q^N - A*Q + (A-1) = 0 1038 which lies between 0 and 1. (Q = 1 is always a root. If N is odd 1039 there is also a negative root.) This may be solved numerically, for 1040 example with Newton's method (see any standard text, for example 1042 [ANM]). The first-order approximation 1044 Q1 = 1 - 1/A 1046 may be used as a starting point for iteration. But Q1 should NOT be 1047 used as an approximate solution as it always underestimates Q, and 1048 hence overestimates p(N), which would cause an overestimate of the 1049 confidence level. 1051 If necessary, the spurious root Q = 1 can be divided out, leaving 1053 Q^(N-1) + Q^(N-2) + ... + Q - (A-1) = 0 1055 as the equation to solve. Depending on the numerical method used, 1056 this could be desirable as it's just possible (but very unlikely) 1057 that A=N and so Q=1 was a double root of the earlier equation. 1059 After N > 2 (or N >= Nmin) intervals have been completed, Compute 1060 the lower-bound reliability estimate 1062 p(N) = R(N,F)/((N-F)*(M(N) - M(F))). 1064 Compute the confidence estimate 1066 c(N) = (1 - (1-p(N))^N)^(M(N) - M(F) + 1). 1068 which is the Bayesian probability that M(N) is the number of routers 1069 present given the number of responses which were collected, as 1070 opposed to M(N)+1 or any greater number. It is assumed that the a 1071 priori probability of there being K routers was no greater than that 1072 of K-1 routers, for all K > M(N). 1074 When c(N) >= Ct and N >= Nmin, retransmissions of the Command may 1075 cease. Otherwise another transmission should be scheduled at a time 1076 V*T(N) + MaxDelay after the previous (Nth) transmission, or V*T(N) 1077 after the conclusion of processing responses to the Nth 1078 transmission, whichever is later. 1080 One corner case needs consideration. Divide-by-zero may occur when 1081 computing p. This can happen only when no new routers have been 1082 heard from in the last N-F intervals. Generally, the confidence 1083 estimate c(N) will be close to unity by then, but in a pathological 1084 case such as a large number of routers with reliable communication 1085 and a much smaller number with very poor communication, the 1086 confidence estimate may still be less than Ct when p's denominator 1087 vanishes. The implementation may continue, and should continue if 1088 the minimum number of transmissions given in the previous paragraph 1089 have not yet been made. If new routers are heard from, p(N) will 1090 again be non-singular. 1092 Of course no limited retransmission scheme can fully address the 1093 possibility of long-term problems, such as a partitioned network. 1094 The network manager is expected to be aware of such conditions when 1095 they exist. 1097 9.3. Additional Assurance Methods 1099 As a final means to detect routers which become reachable after 1100 missing renumbering commands during an extended network split, a 1101 management station MAY adopt the following strategy. When 1102 performing each new operation, increment the SequenceNumber by more 1103 than one. After the operation is believed complete, periodically 1104 send some "no-op" RR Command with the R (Result Requested) flag set 1105 and a SequenceNumber one less than the highest used. Any responses 1106 to such a command can only come from router that missed the last 1107 operation. An example of a suitable "no-op" command would be an ADD 1108 operation with MatchLen = 0, MinLen = 0, MaxLen = 128, and no Use- 1109 Prefix Parts. 1111 If old authentication keys are saved by the management station, even 1112 the reappearance of routers which missed a Sequence Number Reset can 1113 be detected by the transmission of no-op commands with the invalid 1114 key and a SequenceNumber higher than any used before the key was 1115 invalidated. Since there is no other way for a management station 1116 to distinguish a router's failure to receive an entire sequence of 1117 repeated SNR messages from the loss of that router's single SNR 1118 Result Message, this is the RECOMMENDED way to test for universal 1119 reception of a SNR Command. 1121 10. Usage Examples 1123 This section sketches some sample applications of Router 1124 Renumbering. Extension headers, including required IPsec headers, 1125 between the IPv6 header and the ICMPv6 header are not shown in the 1126 examples. 1128 10.1. Maintaining Global-Scope Prefixes 1130 A simple use of the Router Renumbering mechanism, and one which is 1131 expected to to be common, is the maintenance of a set of global 1132 prefixes with a subnet structure that matches that of the site's 1133 site-local address assignments. In the steady state this would 1134 serve to keep the Preferred and Valid lifetimes set to their desired 1135 values. During a renumbering transition, similar Command messages 1136 can add new prefixes and/or delete old ones. An outline of a 1137 suitable Command message follows. Fields not listed are presumed 1138 set to suitable values. This Command assumes all router interfaces 1139 to be maintained already have site-local [AARCH] addresses. 1141 IPv6 Header 1142 Next Header = 58 (ICMPv6) 1143 Source Address = (Management Station) 1144 Destination Address = FF05::2 (All Routers, site-local scope) 1146 ICMPv6/RR Header 1147 Type = 138 (Router Renumbering), Code = 0 (Command) 1148 Flags = 60 hex (R, A) 1150 First (and only) PCO: 1152 Match-Prefix Part 1153 OpCode = 3 (SET-GLOBAL) 1154 OpLength = 4 N + 3 (assuming N global prefixes) 1155 Ordinal = 0 (arbitrary) 1156 MatchLen = 10 1157 MatchPrefix = FEC0::0 1159 First Use-Prefix Part 1160 UseLen = 48 (Length of TLA ID + RES + NLA ID [AARCH]) 1161 KeepLen = 16 (Length of SLA (subnet) ID [AARCH]) 1162 FlagMask, RAFlags, Lifetimes, V & P flags -- as desired 1163 UsePrefix = First global /48 prefix 1165 . . . 1167 Nth Use-Prefix Part 1168 UseLen = 48 1169 KeepLen = 16 1170 FlagMask, RAFlags, Lifetimes, V & P flags -- as desired 1171 UsePrefix = Last global /48 prefix 1173 This will cause N global prefixes to be set (or updated) on each 1174 applicable interface. On each interface, the SLA ID (subnet) field 1175 of each global prefix will be copied from the existing site-local 1176 prefix. 1178 10.2. Renumbering a Subnet 1180 A subnet can be gracefully renumbered by setting the valid and 1181 preferred timers on the old prefix to a short value and having them 1182 run down, while concurrently adding adding the new prefix. Later, 1183 the expired prefix is deleted. The first step is described by the 1184 following RR Command. 1186 IPv6 Header 1187 Next Header = 58 (ICMPv6) 1188 Source Address = (Management Station) 1189 Destination Address = FF05::2 (All Routers, site-local scope) 1191 ICMPv6/RR Header 1192 Type = 138 (Router Renumbering), Code = 0 (Command) 1193 Flags = 60 hex (R, A) 1195 First (and only) PCO: 1197 Match-Prefix Part 1198 OpCode = 2 (CHANGE) 1199 OpLength = 11 (reflects 2 Use-Prefix Parts) 1200 Ordinal = 0 (arbitrary) 1201 MatchLen = 64 1202 MatchPrefix = Old /64 prefix 1204 First Use-Prefix Part 1205 UseLen = 0 1206 KeepLen = 64 (this retains the old prefix value intact) 1207 FlagMask = 0, RAFlags = 0 1208 Valid Lifetime = 28800 seconds (8 hours) 1209 Preferred Lifetime = 7200 seconds (2 hours) 1210 V flag = 1, P flag = 1 1211 UsePrefix = 0::0 1213 Second Use-Prefix Part 1214 UseLen = 64 1215 KeepLen = 0 1216 FlagMask = 0, RAFlags = 0 1217 Lifetimes, V & P flags -- as desired 1218 UsePrefix = New /64 prefix 1220 The second step, deletion of the old prefix, can be done by an RR 1221 Command with the same Match-Prefix Part (except for an OpLength 1222 reduced from 11 to 3) and no Use-Prefix Parts. Any temptation to 1223 set KeepLen = 64 in the second Use-Prefix Part above should be 1224 resisted, as it would instruct the router to sidestep address 1225 configuration. 1227 11. Acknowledgments 1229 This protocol was designed by Matt Crawford based on an idea of 1230 Robert Hinden and Geert Jan de Groot. Many members of the IPNG 1231 Working Group contributed useful comments, in particular members of 1232 the DIGITAL UNIX IPv6 team. Bill Sommerfeld provided helpful IPsec 1233 expertise. Relentless browbeating by various IESG members may have 1234 improved the final quality of this specification. 1236 12. References 1238 [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing 1239 Architecture", RFC 2373. 1241 [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402. 1243 [ANM] Isaacson, E. and H. B. Keller, "Analysis of Numerical Methods", 1244 John Wiley & Sons, New York, 1966. 1246 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1247 (ESP)", RFC 2406. 1249 [IANACON] Narten, T. and H. T. Alvestrand, "Guidelines for Writing 1250 an IANA Considerations Section in RFCs", RFC 2434. 1252 [ICMPV6] Conta, A. and S. Deering, "Internet Control Message 1253 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", 1254 RFC 2460. 1256 [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the 1257 Internet Protocol", RFC 2401. 1259 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1260 (IPv6) Specification", RFC 2460. 1262 [IPV6MIB] Haskin, D. and S. Onishi, "Management Information Base for 1263 IP Version 6: Textual Conventions and General Group", RFC 2466. 1265 [KWORD] Bradner, S., "Key words for use in RFCs to Indicate 1266 Requirement Levels," RFC 2119. 1268 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1269 for IP Version 6 (IPv6)", RFC 2461. 1271 [OSPFMIB] Baker, F. and R. Coltun, "OSPF Version 2 Management 1272 Information Base", RFC 1850. 1274 13. Author's Address 1276 Matt Crawford 1277 Fermilab MS 368 1278 PO Box 500 1279 Batavia, IL 60510 1280 USA 1282 Phone: +1 630 840 3461 1283 Email: crawdad@fnal.gov 1285 Appendix -- Derivation of Reliability Estimates 1287 If a population S of size k is repeatedly sampled with an efficiency 1288 p, the expected number of members of S first discovered on the nth 1289 sampling is 1291 m = [1 - (1-p)^n] * k 1293 The expected total number of members of S found in samples, 1294 including duplicates, is 1296 r = n * p * k 1298 Taking the ratio of m to r cancels the unknown factor k and yields 1299 an equation 1301 [1 - (1-p)^n] / p = nm/r 1303 which may be solved for p, which is then an estimator of the 1304 sampling efficiency. (The statistical properties of the estimator 1305 will not be examined here.) Under the substitution p = 1-q, this 1306 becomes the first equation of Section 9.2. 1308 With the estimator p in hand, and a count m of members of S 1309 discovered after n samplings, we can compute the a posteriori 1310 probability that the true size of S is m+j, for j >= 0. Let Hj 1311 denote the hypothesis that the true size of S is m+j, and let R 1312 denote the result that m members have been found in n samplings. 1313 Then 1315 P{R | Hj} = [(m+j)!/m!j!] * [1-(1-p)^n]^m * [(1-p)^n]^j 1317 We are interested in P{H0 | R}, but to find it we need to assign a 1318 priori values to P{Hj}. Let the size of S be exponentially 1319 distributed 1321 P{Hj} / P{H0} = h^(-j) 1323 for arbitrary h in (0, 1). The value of h will be eliminated from 1324 the result. 1326 The Bayesian method yields 1328 P{Hj | R} / P{H0 | R} = [(m+j)!/m!j!] * [h*(1-p)^n]^j 1330 The reciprocal of the sum over j >= 0 of these ratios is 1332 P{H0 | R} = [1-h*(1-p)^n] ^ (m+1) 1334 and the confidence estimate of Section 9.2 is the h -> 1 limit of 1335 this expression.