idnits 2.17.1 draft-ietf-ipngwg-router-renum-05.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-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 634 has weird spacing: '...pLength mus...' == Line 638 has weird spacing: '...atchLen mus...' == Line 846 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 (September 17, 1998) is 9346 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 494, 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. -- 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. -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-mib is -03, but you're referring to -04. ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-ipv6-mib (ref. 'IPV6MIB') -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-discovery-v2 is -02, but you're referring to -03. Summary: 10 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 September 17, 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. Security Considerations ....................................... 18 72 7.1. Security Policy and Association Database Entries ........ 18 74 8. Usage Examples ................................................ 19 75 8.1. Maintaining Global-Scope Prefixes ....................... 19 76 8.2. Renumbering a Subnet .................................... 20 78 9. Acknowledgments ............................................... 21 80 10. References ................................................... 22 82 11. Author's Address ............................................. 22 83 2. Functional Overview 85 Router Renumbering Command packets contain a sequence of Prefix 86 Control Operations (PCOs). Each PCO specifies an operation, a 87 Match-Prefix, and zero or more Use-Prefixes. A router processes 88 each PCO in sequence, checking each of its interfaces for an address 89 or prefix which matches the Match-Prefix. For every interface on 90 which a match is found, the operation is applied. The operation is 91 one of ADD, CHANGE, or SET-GLOBAL to instruct the router to 92 respectively add the Use-Prefixes to the set of configured prefixes, 93 remove the prefix which matched the Match-Prefix and replace it with 94 the Use-Prefixes, or replace all global-scope prefixes with the 95 Use-Prefixes. If the set of Use-Prefixes in the PCO is empty, the 96 ADD operation does nothing and the other two reduce to deletions. 98 Additional information for each Use-Prefix is included in the Prefix 99 Control Operation: the valid and preferred lifetimes to be included 100 in Router Advertisement Prefix Information Options [ND], and either 101 the L and A flags for the same option, or an indication that they 102 are to be copied from the prefix that matched the Match-Prefix. 104 It is possible to instruct routers to create new prefixes by 105 combining the Use-Prefixes in a PCO with some portion of the 106 existing prefix which matched the Match-Prefix. This simplifies 107 certain operations which are expected to be among the most common. 108 For every Use-Prefix, the PCO specifies a number of bits which 109 should be copied from the existing address or prefix which matched 110 the Match-Prefix and appended to the use-prefix prior to configuring 111 the new prefix on the interface. The copied bits are zero or more 112 bits from the positions immediately after the length of the Use- 113 Prefix. If subnetting information is in the same portion of the old 114 and new prefixes, this synthesis allows a single Prefix Control 115 Operation to define a new global prefix on every router in a site, 116 while preserving the subnetting structure. 118 Because of the power of the Router Renumbering mechanism, each RR 119 message includes a sequence number to guard against replays, and is 120 required to be authenticated and integrity-checked. Each single 121 Prefix Control Operation is idempotent and so could be retransmitted 122 for improved reliability, as long as the sequence number is current, 123 without concern about multiple processing. However, non-idempotent 124 combinations of PCOs can easily be constructed and messages 125 containing such combinations could not be safely reprocessed. 126 Therefore, all routers are required to guard against processing an 127 RR message more than once. To allow reliable verification that 128 Commands have been received and processed by routers, a mechanism 129 for duplicate-command notification to the management station is 130 included. 132 Possibly a network manager will want to perform more renumbering, or 133 exercise more detailed control, than can be expressed in a single 134 Router Renumbering packet on the available media. The RR mechanism 135 is most powerful when RR packets are multicast, so IP fragmentation 136 is undesirable. For these reasons, each RR packet contains a 137 "Segment Number". All RR packets which have a Sequence Number 138 greater than or equal to the highest value seen are valid and must 139 be processed. However, a router must keep track of the Segment 140 Numbers of RR messages already processed and avoid reprocessing a 141 message whose Sequence Number and Segment Number match a previously 142 processed message. (This list of processed segment numbers is reset 143 when a new highest Sequence Number is seen.) 145 The Segment Number does not impose an ordering on packet processing. 146 If a specific sequence of operations is desired, it may be achieved 147 by ordering the PCOs in a single RR Command message or through the 148 Sequence Number field. 150 There is a "Test" flag which indicates that all routers should 151 simulate processing of the RR message and not perform any actual 152 reconfiguration. A separate "Report" flag instructs routers to send 153 a Router Renumbering Result message back to the source of the RR 154 Command message indicating the actual or simulated result of the 155 operations in the RR Command message. 157 The effect or simulated effect of an RR Command message may also 158 reported to network management by means outside the scope of this 159 document, regardless of the value of the "Report" flag. 161 3. Definitions 163 3.1. Terminology 165 Address 166 This term always refers to a 128-bit IPv6 address [AARCH]. When 167 referring to bits within an address, they are numbered from 0 to 168 127, with bit 0 being the first bit of the Format Prefix. 170 Prefix 171 A prefix can be understood as an address plus a length, the 172 latter being an integer in the range 0 to 128 indicating how many 173 leading bits are significant. When referring to bits within a 174 prefix, they are numbered in the same way as the bits of an 175 address. For example, the significant bits of a prefix whose 176 length is L are the bits numbered 0 through L-1, inclusive. 178 Match 179 An address A "matches" a prefix P whose length is L if the first 180 L bits of A are identical with the first L bits of P. (Every 181 address matches a prefix of length 0.) A prefix P1 with length 182 L1 matches a prefix P2 of length L2 if L1 >= L2 and the first L2 183 bits of P1 and P2 are identical. 185 Prefix Control Operation 186 This is the smallest individual unit of Router Renumbering 187 operation. A Router Renumbering Command packet includes zero or 188 more of these, each comprising one matching condition, called a 189 Match-Prefix Part, and zero or more substitution specifications, 190 called Use-Prefix Parts. 192 Match-Prefix 193 This is a Prefix against which a router compares the addresses 194 and prefixes configured on its interfaces. 196 Use-Prefix 197 The prefix and associated information which is to be configured 198 on a router interface when certain conditions are met. 200 Matched Prefix 201 The existing prefix or address which matched a Match-Prefix. 203 New Prefix 204 A prefix constructed from a Use-Prefix, possibly including some 205 of the Matched Prefix. 207 Recorded Sequence Number 208 The highest sequence number found in a valid message MUST be 209 recorded in non-volatile storage. 211 Note that "matches" is a transitive relation but not symmetric. 212 If two prefixes match each other, they are identical. 214 3.2. Requirements 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [KWORD]. 220 4. Message Format 222 There are two types of Router Renumbering messages: Commands, which 223 are sent to routers, and Results, which are sent by routers. A 224 third message type is used to synchronize a reset of the Recorded 225 Sequence Number with the cancellation of cryptographic keys. The 226 three types of messages are distinguished the ICMPv6 "Code" field 227 and differ in the contents of the "Message Body" field. 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 / IPv6 header, extension headers / 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 / ICMPv6 & RR Header (16 octets) / 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 / RR Message Body / 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Router Renumbering Message Format 245 Router Renumbering messages are carried in ICMPv6 packets with 246 Type = 138. The RR message comprises an RR Header, containing the 247 ICMPv6 header, the sequence and segment numbers and other 248 information, and the RR Message Body, of variable length. 250 All fields marked "reserved" or "res" MUST be set to zero on 251 generation of an RR message. 253 All implementations which generate Router Renumbering Command 254 messages MUST support sending them to the All Routers multicast 255 address with link and site scopes, and to unicast addresses of 256 link-local and site-local formats. All routers MUST be capable of 257 receiving RR Commands sent to those multicast addresses and to any 258 of their link local and site local unicast addresses. 259 Implementations SHOULD support sending and receiving RR messages 260 addressed to other unicast addresses. An implementation which is 261 both a sender and receiver of RR commands SHOULD support use of the 262 All Routers multicast address with node scope. 264 Data authentication and message integrity MUST be provided for all 265 Router Renumbering Command messages by appropriate IP Security 266 [IPSEC] means. The integrity assurance must include the IPv6 267 destination address and the RR Header and Message Body. See section 268 7, "Security Considerations". 270 The use of authentication for Router Renumbering Result messages is 271 RECOMMENDED. 273 4.1. Router Renumbering Header 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Code | Checksum | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | SequenceNumber | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | SegmentNumber | Flags | MaxDelay | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | reserved | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Fields: 289 Type 138 (decimal), the ICMPv6 type value assigned to Router 290 Renumbering 292 Code 0 for a Router Renumbering Command 293 1 for a Router Renumbering Result 294 255 for a Sequence Number Reset. 295 The Sequence Number Reset is described in section 6. 297 Checksum The ICMPv6 checksum, as specified in [ICMPV6]. The 298 checksum covers the IPv6 pseudo-header and all fields of 299 the RR message from the Type field onward. 301 SequenceNumber 302 An unsigned 32-bit sequence number. The sequence number 303 MUST be non-decreasing between Sequence Number Resets. 305 SegmentNumber 306 An unsigned 8-bit field which enumerates different valid 307 RR messages having the same SequenceNumber. No ordering 308 among RR messages is imposed by the SegmentNumber. 310 Flags A combination of one-bit flags. Six are defined and two 311 bits are reserved. 313 +-+-+-+-+-+-+-+-+ 314 |T|R|A|S|P| res | 315 +-+-+-+-+-+-+-+-+ 317 The flags T, R, A and S have defined meanings in an RR 318 Command message. In a Result message they MUST be 319 copied from the corresponding Command. The P flag is 320 meaningful only in a Result message and MUST be zero in 321 a Command. 323 T 0 indicates that the router configuration is to be 324 modified; 325 1 indicates a "Test" message: processing is to be 326 simulated and no configuration changes are to be 327 made. 329 R 0 indicates that a Result message MUST NOT be sent 330 (but other forms of logging are not precluded); 331 1 indicates that the router MUST send a Result 332 message upon completion of processing the Command 333 message; 335 A 0 indicates that the Command MUST NOT be applied to 336 interfaces which are administratively shut down; 337 1 indicates that the Command MUST be applied to 338 interfaces regardless of administrative shutdown 339 status. 341 S This flag MUST be ignored unless the router treats 342 interfaces as belonging to different "sites". 343 0 indicates that the Command MUST be applied to 344 interfaces regardless of which site they belong 345 to; 346 1 indicates that the Command MUST be applied only to 347 interfaces which belong to the same site as the 348 interface to which the Command is addressed. If 349 the destination address is appropriate for 350 interfaces belonging to more than one site, then 351 the Command MUST be applied only to interfaces 352 belonging to the same site as the interface on 353 which the Command was received. 355 P 0 indicates that the Result message contains the 356 complete report of processing the Command; 357 1 indicates that the Command message was previously 358 processed (and is not a Test) and the responding 359 router is not processing it again. This Result 360 message MAY have an empty body. 362 MaxDelay An unsigned 16-bit field specifying the maximum time, in 363 milliseconds, by which a router MUST delay sending any 364 reply to this Command. Implementations MAY generate the 365 random delay between 0 and MaxDelay milliseconds with a 366 finer granularity than 1ms. 368 4.2. Message Body -- Command Message 370 The body of an RR Command message is a sequence of zero or more 371 Prefix Control Operations, each of variable length. The end of the 372 sequence MAY be inferred from the IPv6 length and the lengths of 373 extension headers which precede the ICMPv6 header. 375 4.2.1. Prefix Control Operation 377 A Prefix Control Operation has one Match-Prefix Part of 24 octets, 378 followed by zero or more Use-Prefix Parts of 32 octets each. 380 4.2.1.1. Match-Prefix Part 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | OpCode | OpLength | Ordinal | MatchLen | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | MinLen | MaxLen | reserved | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | 390 +- -+ 391 | | 392 +- MatchPrefix -+ 393 | | 394 +- -+ 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Fields: 400 OpCode An unsigned 8-bit field specifying the operation to be 401 performed when the associated MatchPrefix matches an 402 interface's prefix or address. Values are: 404 1 the ADD operation 406 2 the CHANGE operation 408 3 the SET-GLOBAL operation 410 OpLength The total length of this Prefix Control Operation, in 411 units of 8 octets. A valid OpLength will always be of 412 the form 4N+3, with N equal to the number of UsePrefix 413 parts (possibly zero). 415 Ordinal An 8-bit field which MUST have a different value in each 416 Prefix Control Operation contained in a given RR Command 417 message. The value is otherwise unconstrained. 419 MatchLen An 8-bit unsigned integer between 0 and 128 inclusive 420 specifying the number of initial bits of MatchPrefix 421 which are significant in matching. 423 MinLen An 8-bit unsigned integer specifying the minimum length 424 which any configured prefix must have in order to be 425 eligible for testing against the MatchPrefix. 427 MaxLen An 8-bit unsigned integer specifying the maximum length 428 which any configured prefix may have in order to be 429 eligible for testing against the MatchPrefix. 431 MatchPrefix The 128-bit prefix to be compared with each interface's 432 prefix or address. 434 4.2.1.2. Use-Prefix Part 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | UseLen | KeepLen | FlagMask | RAFlags | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Valid Lifetime | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Preferred Lifetime | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |V|P| reserved | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 +- -+ 449 | | 450 +- UsePrefix -+ 451 | | 452 +- -+ 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Fields: 458 UseLen An 8-bit unsigned integer less than or equal to 128 459 specifying the number of initial bits of UsePrefix to 460 use in creating a new prefix for an interface. 462 KeepLen An 8-bit unsigned integer less than or equal to (128- 463 UseLen) specifying the number of bits of the prefix or 464 address which matched the associated Match-Prefix which 465 should be retained in the new prefix. The retained bits 466 are those at positions UseLen through (UseLen+KeepLen-1) 467 in the matched address or prefix, and they are copied to 468 the same positions in the New Prefix. 470 FlagMask An 8-bit mask. A 1 bit in any position means that the 471 corresponding flag bit in a Router Advertisement (RA) 472 Prefix Information Option for the New Prefix should be 473 set from the RAFlags field in this Use-Prefix Part. A 0 474 bit in the FlagMask means that the RA flag bit for the 475 New Prefix should be copied from the corresponding RA 476 flag bit of the Matched Prefix. 478 RAFlags An 8 bit field which, under control of the FlagMask 479 field, may be used to initialize the flags in Router 480 Advertisement Prefix Information Options [ND] which 481 advertise the New Prefix. Note that only two flags have 482 defined meanings to date: the L (on-link) and A 483 (autonomous configuration) flags. These flags occupy 484 the two leftmost bit positions in the RAFlags field, 485 corresponding to their position in the Prefix 486 Information Option. 488 Valid Lifetime 489 A 32-bit unsigned integer which is the number of seconds 490 for which the New Prefix will be valid [ND, SAA]. 492 Preferred Lifetime 493 A 32-bit unsigned integer which is the number of seconds 494 for which the New Prefix will be preferred [ND, SAA]. 496 V A 1-bit flag indicating that the valid lifetime of the 497 New Prefix MUST be effectively decremented in real time. 499 P A 1-bit flag indicating that the preferred lifetime of 500 the New Prefix MUST be effectively decremented in real 501 time. 503 UsePrefix The 128-bit Use-prefix which either becomes or is used 504 in forming (if KeepLen is nonzero) the New Prefix. It 505 MUST NOT have the form of a multicast or link-local 506 address [AARCH]. 508 4.3. Message Body -- Result Message 510 The body of an RR Result message is a sequence of zero or more Match 511 Reports of 24 octets. An RR Command message with the "R" flag set 512 will elicit an RR Result message containing one Match Report for 513 each Prefix Control Operation, for each different prefix it matches 514 on each interface. The Match Report has the following format. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | reserved |B|F| Ordinal | MatchedLen | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | InterfaceIndex | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | | 524 +- -+ 525 | | 526 +- MatchedPrefix -+ 527 | | 528 +- -+ 529 | | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Fields: 534 B A one-bit flag which, when set, indicates that one or 535 more fields in the associated PCO were out of bounds. 536 The bounds check is described in section 5.3. 538 F A one-bit flag which, when set, indicates that one or 539 more Use-Prefix parts from the associated PCO were not 540 honored by the router because of attempted formation of 541 a forbidden prefix format, such as a multicast or 542 loopback address. 544 Ordinal Copied from the Prefix Control Operation whose 545 MatchPrefix matched the MatchedPrefix on the interface 546 indicated by InterfaceIndex. 548 MatchedLen The length of the Matched Prefix. 550 InterfaceIndex 551 The router's numeric designation of the interface on 552 which the MatchedPrefix was configured. This MUST be 553 the same as the value of ipv6IfIndex which designates 554 that index in the SNMP IPv6 MIB General Group [IPV6MIB]. 556 It is possible for a Result message to be larger than the Command 557 message which elicited it. Such a Result message may have to be 558 fragmented for transmission. If so, it SHOULD be fragmented to the 559 IPv6 minimum required MTU [IPV6]. 561 5. Message Processing 563 Processing of received Router Renumbering Result messages is 564 entirely implementation-defined. Implementation of Command message 565 processing may vary in detail from the procedure set forth below, so 566 long as the result is not affected. 568 Processing of received Router Renumbering Command messages consists 569 of three conceptual parts: header check, bounds check, and 570 execution. 572 5.1. Header Check 574 The ICMPv6 checksum and type are presumed to have been checked 575 before a Router Renumbering module receives a Command to process. 576 In an implementation environment where this may not be the case, 577 those checks MUST be made at this point in the processing. 579 If the ICMPv6 length derived from the IPv6 length is less than 16 580 octets, the message MUST be discarded and SHOULD be logged to 581 network management. 583 If the ICMPv6 Code field indicates a Result message, a router which 584 is not a source of RR Command messages MUST discard the message and 585 SHOULD NOT log it to network management. 587 If the IPv6 destination address is neither an All Routers multicast 588 address [AARCH] nor one of the receiving router's unicast addresses, 589 the message MUST be discarded and SHOULD be logged to network 590 management. 592 Next, the SequenceNumber is compared to the Recorded Sequence 593 Number. (If no RR messages have been received and accepted since 594 system initialization, the Recorded Sequence Number is zero.) This 595 comparison is done with the two numbers considered as unsigned 596 integers, not as DNS-style serial numbers. If the SequenceNumber is 597 less than the Recorded Sequence Number, the message MUST be 598 discarded and SHOULD be logged to network management. 600 Finally, if the SequenceNumber in the message is greater than the 601 Recorded Sequence Number or the T flag is set, skip to the bounds 602 check. Otherwise the SegmentNumber MUST now be checked. If a 603 correctly authenticated message with the same SequenceNumber and 604 SegmentNumber has not already been processed, skip to the bounds 605 check. Otherwise, this Command is a duplicate and not a Test 606 Command. If the R flag is not set, the duplicate message MUST be 607 discarded and SHOULD NOT be logged to network management. If R is 608 set, an RR Result message with the P flag set MUST be scheduled for 609 transmission to the source address of the Command after a random 610 time uniformly distributed between 0 and MaxDelay milliseconds. The 611 body of that Result message MUST either be empty or be a saved copy 612 of the Result message body generated by processing of the previous 613 message with the same SequenceNumber and SegmentNumber. After 614 scheduling the Result message, the Command MUST be discarded without 615 further processing. 617 5.2. Bounds Check 619 If the ICMPv6 Code field indicates a Sequence Number Reset, skip to 620 section 6. 622 At this point, if T is set in the RR header and R is not set, the 623 message MAY be discarded without further processing. 625 If the R flag is set, begin constructing an RR Result message. The 626 RR header of the Result message is completely determined at this 627 time except for the Checksum. 629 The values of the following fields of a PCO MUST be checked to 630 ensure that they are within the appropriate bounds. 632 OpCode must be a defined value. 634 OpLength must be of the form 4N+3 and consistent the the length 635 of the Command packet and the PCO's offset within the 636 packet. 638 MatchLen must be between 0 and 128 inclusive 640 UseLen, KeepLen 641 in each Use-Prefix Part must be between 0 and 128 642 inclusive, as must the sum of the two. 644 If any of these fields are out of range in a PCO, the entire PCO 645 MUST NOT be performed on any interface. If the R flag is set in the 646 RR header then add to the RR Result message a Match Report with the 647 B flag set, the F flag clear, the Ordinal copied from the PCO, and 648 all other fields zero. This Match Report MUST be included only 649 once, not once per interface. 651 Note that MinLen and MaxLen need not be explicitly bounds checked, 652 even though certain combinations of values will make any matches 653 impossible. 655 5.3. Execution 657 For each applicable router interface, as determined by the A and S 658 flags, the Prefix Control Operations in an RR Command message must 659 be carried out in order of appearance. The relative order of PCO 660 processing among different interfaces is not specified. 662 If the T flag is set, create a copy of each interface's 663 configuration on which to operate, because the results of processing 664 a PCO may affect the processing of subsequent PCOs. Note that if 665 all operations are performed on one interface before proceeding to 666 another interface, only one interface-configuration copy will be 667 required at a time. 669 For each interface and for each Prefix Control Operation, each 670 prefix configured on that interface with a length between the MinLen 671 and MaxLen values in the PCO is tested to determine whether it 672 matches (as defined in section 3.1) the MatchPrefix of the PCO. The 673 configured prefixes are tested in an arbitrary order. Any new 674 prefix configured on an interface by the effect of a given PCO MUST 675 NOT be tested against that PCO, but MUST be tested against all 676 subsequent PCOs in the same RR Command message. 678 Under a certain condition the addresses on an interface are also 679 tested to see whether any of them matches the MatchPrefix. If and 680 only if a configured prefix "P" does have a length between MinLen 681 and MaxLen inclusive, does not match the MatchPrefix "M", but M does 682 match P (this can happen only if M is longer than P), then those 683 addresses on that interface which match P MUST be tested to 684 determine whether any of them matches M. If any such address does 685 match M, process the PCO as if P matched M, but when forming New 686 Prefixes, if KeepLen is non-zero, bits are copied from the address. 687 This special case allows a PCO to be easily targeted to a single 688 specific interface in a network. 690 If P does not match M, processing is finished for this combination 691 of PCO, interface and prefix. Continue with another prefix on the 692 same interface if there are any more prefixes which have not been 693 tested against this PCO and were not created by the action of this 694 PCO. If no such prefixes remain on the current interface, continue 695 processing with the next PCO on the same interface, or with another 696 interface. 698 If P does match M, either directly or because a configured address 699 which matches P also matches M, then P is the Matched Prefix. 700 Perform the following steps. 702 If the Command has the R flag set, add a Match Report to 703 the Result message being constructed. 705 If the OpCode is CHANGE, mark P for deletion from the 706 current interface. 708 If the OpCode is SET-GLOBAL, mark all global-scope 709 prefixes on the current interface for deletion. 711 If there are any Use-Prefix parts in the current PCO, form 712 the New Prefixes. Discard any New Prefix which has a 713 forbidden format, and if the R flag is set in the command, 714 set the F flag in the Match Report for this PCO and 715 interface. Forbidden prefix formats include, at a 716 minimum, multicast, unspecified and loopback addresses. 717 [AARCH] Any implementation MAY forbid, or allow the 718 network manager to forbid other formats as well. 720 For each New Prefix which is already configured on the 721 current interface, unmark that prefix for deletion and 722 update the lifetimes and RA flags. For each New Prefix 723 which is not already configured, add the prefix and, if 724 appropriate, configure an address with that prefix. 726 Delete any prefixes which are still marked for deletion, 727 together with any addresses which match those prefixes but 728 do not match any prefix which is not marked for deletion. 730 After processing all the Prefix Control Operations on all 731 the interfaces, an implementation MUST record the 732 SegmentNumber of the packet in a list associated with the 733 SequenceNumber. 735 If the Command has the R flag set, compute the Checksum 736 and schedule the Result message for transmission after a 737 random time uniformly distributed between 0 and MaxDelay 738 milliseconds. A copy of the Result message MAY be saved 739 to be retransmitted in response to a duplicate Command. 741 5.4. Summary of Effects 743 The only Neighbor Discovery [ND] parameters which can be affected by 744 Router Renumbering are the following. 746 A router's addresses and advertised prefixes, including the 747 prefix lengths. 749 The flag bits (L and A, and any which may be defined in the 750 future) and the valid and preferred lifetimes which appear in a 751 Router Advertisement Prefix Information Option. 753 The unnamed property of the lifetimes, which specifies whether 754 they are fixed or decrementing. 756 Other internal router information, such as the time until the next 757 unsolicited Router Advertisement or MIB variables MAY be affected as 758 needed. 760 All configuration changes resulting from Router Renumbering SHOULD 761 be saved to non-volatile storage where this facility exists. The 762 problem of properly restoring prefix lifetimes from non-volatile 763 storage exists independently of Router Renumbering and deserves 764 careful attention, but is outside the scope of this document. 766 6. Sequence Number Reset 768 It may prove necessary in practice to reset a router's Recorded 769 Sequence Number. This is a safe operation only when all 770 cryptographic keys previously used to authenticate RR Commands have 771 expired or been revoked. For this reason, the Sequence Number Reset 772 message is defined to accomplish both functions. 774 When a Sequence Number Reset (SNR) has been authenticated and has 775 passed the header check, the router MUST invalidate all keys which 776 have been used to authenticate previous RR Commands, including the 777 key which authenticated the SNR itself Then it MUST discard any 778 saved RR Result messages, clear the list of recorded SegmentNumbers 779 and reset the Recorded Sequence Number to zero. 781 The router SHOULD establish one or more new authentication keys for 782 Router Renumbering use. The details of this process will depend on 783 whether manual keying or a key management protocol is used. In 784 either case, if no new keys can be established, no new Commands can 785 be processed. 787 Note that a SNR message SHOULD contain no PCOs, since they will be 788 ignored. 790 7. Security Considerations 792 The Router Renumbering mechanism proposed here is very powerful and 793 prevention of spoofing it is important. Replay of old messages must 794 be prevented, except in the narrow case of idempotent messages which 795 are still valid. (These are intended to be replayed for 796 reliability's sake.) What constitutes a sufficiently strong 797 authentication algorithm may change from time to time, but 798 algorithms should be chosen which are strong against current key- 799 recovery and forgery attacks. 801 Authentication keys must be as well protected as is any other access 802 method that allows reconfiguration of a site's routers. 803 Distribution of keys must not expose them or permit alteration, and 804 key validity must be limited in terms of time and number of messages 805 authenticated. 807 Note that although a reset of the Recorded Sequence Number requires 808 the cancellation of previously-used authentication keys, 809 introduction of new keys and expiration of old keys does not require 810 resetting the Recorded Sequence Number. 812 7.1. Security Policy and Association Database Entries 814 The Security Policy Database (SPD) [IPSEC] of a router implementing 815 this specification MUST cause incoming Router Renumbering Command 816 packets to either be discarded or have IPsec applied. (The 817 determination of "discard" or "apply" MAY be based on the source 818 address.) The resulting Security Association Database (SAD) entries 819 MUST ensure authentication and integrity of the destination address 820 and the RR Header and Message Body, and the body length implied by 821 the IPv6 length and intervening extension headers. These 822 requirements are met by the use of the Authentication Header [AH] in 823 transport or tunnel mode, or the Encapsulating Security Payload 824 [ESP] in tunnel mode with non-NULL authentication. The mandatory- 825 to-implement IPsec authentication algorithms (other than NULL) seem 826 strong enough for Router Renumbering at the time of this writing. 828 Note that for the SPD to distinguish Router Renumbering from other 829 ICMP packets requires the use of the ICMP Type field as a selector. 830 This is consistent with, although not mentioned by, the Security 831 Architecture specification [IPSEC]. 833 At the time of this writing, there exists no multicast key 834 management protocol for IPsec and none is on the horizon. Manually 835 configured Security Associations will therefore be common. The 836 occurrence of "from traffic" in the table below would therefore more 837 realistically be a wildcard or a fixed range. Use of a small set of 838 shared keys per management station suffices, so long as key 839 distribution and storage are sufficiently safeguarded. 841 A sufficient set of SPD entries for incoming traffic could select 843 Field SPD Entry SAD Entry 844 ------- --------- --------- 845 Source wildcard from traffic 846 Destination wildcard from SPD 847 Transport ICMPv6 from SPD 848 ICMP Type Rtr. Renum. from SPD 849 Action Apply IPsec 850 SA Spec AH/Transport Mode 852 or there might be an entry for each management station and/or for 853 each of the router's unicast addresses and for each of the defined 854 All-Routers multicast addresses, and a final wildcard entry to 855 discard all other incoming RR messages. 857 The SPD and SAD are conceptually per-interface databases. This fact 858 may be exploited to permit shared management of a border router, for 859 example, or to discard all Router Renumbering traffic arriving over 860 tunnels. 862 8. Usage Examples 864 This section sketches some sample applications of Router 865 Renumbering. Extension headers, including required IPsec headers, 866 between the IPv6 header and the ICMPv6 header are not shown in the 867 examples. 869 8.1. Maintaining Global-Scope Prefixes 871 A simple use of the Router Renumbering mechanism, and one which is 872 expected to to be common, is the maintenance of a set of global 873 prefixes with a subnet structure that matches that of the site's 874 site-local address assignments. In the steady state this would 875 serve to keep the Preferred and Valid lifetimes set to their desired 876 values. During a renumbering transition, similar Command messages 877 can add new prefixes and/or delete old ones. An outline of a 878 suitable Command message follows. Fields not listed are presumed 879 set to suitable values. This Command assumes all router interfaces 880 to be maintained already have site-local [AARCH] addresses. 882 IPv6 Header 883 Next Header = 58 (ICMPv6) 884 Source Address = (Management Station) 885 Destination Address = FF05::2 (All Routers, site-local scope) 887 ICMPv6/RR Header 888 Type = 138 (Router Renumbering), Code = 0 (Command) 889 Flags = 60 hex (R, A) 891 First (and only) PCO: 893 Match-Prefix Part 894 OpCode = 3 (SET-GLOBAL) 895 OpLength = 4 N + 3 (assuming N global prefixes) 896 Ordinal = 0 (arbitrary) 897 MatchLen = 10 898 MatchPrefix = FEC0::0 900 First Use-Prefix Part 901 UseLen = 48 (Length of TLA ID + RES + NLA ID [AARCH]) 902 KeepLen = 16 (Length of SLA (subnet) ID [AARCH]) 903 FlagMask, RAFlags, Lifetimes, V & P flags -- as desired 904 UsePrefix = First global /48 prefix 906 . . . 908 Nth Use-Prefix Part 909 UseLen = 48 910 KeepLen = 16 911 FlagMask, RAFlags, Lifetimes, V & P flags -- as desired 912 UsePrefix = Last global /48 prefix 914 This will cause N global prefixes to be set (or updated) on each 915 applicable interface. On each interface, the SLA ID (subnet) field 916 of each global prefix will be copied from the existing site-local 917 prefix. 919 8.2. Renumbering a Subnet 921 A subnet can be gracefully renumbered by setting the valid and 922 preferred timers on the old prefix to a short value and having them 923 run down, while concurrently adding adding the new prefix. Later, 924 the expired prefix is deleted. The first step is described by the 925 following RR Command. 927 IPv6 Header 928 Next Header = 58 (ICMPv6) 929 Source Address = (Management Station) 930 Destination Address = FF05::2 (All Routers, site-local scope) 932 ICMPv6/RR Header 933 Type = 138 (Router Renumbering), Code = 0 (Command) 934 Flags = 60 hex (R, A) 936 First (and only) PCO: 938 Match-Prefix Part 939 OpCode = 2 (CHANGE) 940 OpLength = 11 (reflects 2 Use-Prefix Parts) 941 Ordinal = 0 (arbitrary) 942 MatchLen = 64 943 MatchPrefix = Old /64 prefix 945 First Use-Prefix Part 946 UseLen = 0 947 KeepLen = 64 (this retains the old prefix value intact) 948 FlagMask = 0, RAFlags = 0 949 Valid Lifetime = 28800 seconds (8 hours) 950 Preferred Lifetime = 7200 seconds (2 hours) 951 V flag = 1, P flag = 1 952 UsePrefix = 0::0 954 Second Use-Prefix Part 955 UseLen = 64 956 KeepLen = 0 957 FlagMask = 0, RAFlags = 0 958 Lifetimes, V & P flags -- as desired 959 UsePrefix = New /64 prefix 961 The second step, deletion of the old prefix, can be done by an RR 962 Command with the same Match-Prefix Part (except for an OpLength 963 reduced from 11 to 3) and no Use-Prefix Parts. Any temptation to 964 set KeepLen = 64 in the second Use-Prefix Part above should be 965 resisted, as it would instruct the router to sidestep address 966 configuration. 968 9. Acknowledgments 970 This protocol was designed by Matt Crawford based on an idea of 971 Robert Hinden and Geert Jan de Groot. Many members of the IPNG 972 Working Group contributed useful comments, in particular members of 973 the DIGITAL UNIX IPv6 team. Bill Sommerfeld gave helpful nudges in 974 the IPsec considerations. 976 10. References 978 [AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing 979 Architecture", Currently draft-ietf-ipngwg-addr-arch-v2-07.txt. 981 [AH] S. Kent, R. Atkinson, "IP Authentication Header", Currently 982 draft-ietf-ipsec-auth-header-07.txt. 984 [ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 985 (ESP)", Currently draft-ietf-ipsec-esp-v2-06.txt. 987 [ICMPV6] A. Conta, S. Deering, "Internet Control Message Protocol 988 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", currently 989 draft-ietf-ipngwg-icmp-v2-01.txt. 991 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the 992 Internet Protocol", currently draft-ietf-ipsec-arch-sec-07.txt. 994 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 995 Specification", currently draft-ietf-ipngwg-ipv6-spec-v2-02.txt. 997 [IPV6MIB] D. Haskin, S. Onishi, "Management Information Base for IP 998 Version 6: Textual Conventions and General Group", currently 999 draft-ietf-ipngwg-ipv6-mib-04.txt. 1001 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 1002 Requirement Levels," RFC 2119. 1004 [ND] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP 1005 Version 6 (IPv6)", currently draft-ietf-ipngwg-discovery-v2- 1006 03.txt. 1008 11. Author's Address 1010 Matt Crawford 1011 Fermilab MS 368 1012 PO Box 500 1013 Batavia, IL 60510 1014 USA 1016 Phone: +1 630 840 3461 1017 Email: crawdad@fnal.gov