idnits 2.17.1 draft-ietf-ipngwg-router-renum-02.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. ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ND], [SAA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 1997) is 9646 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: 'ICMPV6' is mentioned on line 240, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-addr-arch-v2-05 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-02 ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') == Outdated reference: A later version (-02) exists of draft-ietf-ipngwg-discovery-v2-00 == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-addrconf-v2-00 Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 2 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 Bob Hinden 4 Ipsilon Networks 5 November 21, 1997 7 Router Renumbering for IPv6 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 "working draft" or "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Distribution of this memo is unlimited. 31 1. Abstract 33 IPv6 Neighbor Discovery [ND] and Address Autoconfiguration [SAA] 34 conveniently make initial assignments of address prefixes to hosts. 35 Aside from the problem of connection survival across a renumbering 36 event, these two mechanisms also simplify the reconfiguration of 37 hosts when the set of valid prefixes changes. 39 This document defines a mechanism called Router Renumbering (''RR'') 40 which allows address prefixes on routers to be configured and 41 reconfigured almost as easily as the combination of Neighbor 42 Discovery and Address Autoconfiguration works for hosts. It 43 provides a means for a network manager to make updates to the 44 prefixes used by and advertised by IPv6 routers throughout a site. 46 2. Functional Overview 48 Router Renumbering Command packets contain a sequence of Prefix 49 Control Operations (PCOs). Each PCO specifies an operation, a 50 Match-Prefix, and zero or more Use-Prefixes. A router processes 51 each PCO in sequence, checking each of its interfaces for an address 52 or prefix which matches the Match-Prefix. For every interface on 53 which a match is found, the operation is applied. The operation is 54 one of ADD, CHANGE, or SET-GLOBAL to instruct the router to 55 respectively add the Use-Prefixes to the set of configured prefixes, 56 remove the prefix which matched the Match-Prefix and replace it with 57 the Use-Prefixes, or replace all global-scope prefixes with the 58 Use-Prefixes. If the set of Use-Prefixes in the PCO is empty, the 59 ADD operation does nothing and the other two reduce to deletions. 61 Additional information for each Use-Prefix is included in the Prefix 62 Control Operation: the valid and preferred lifetimes to be included 63 in Router Advertisement Prefix Information Options [ND], and either 64 the L and A flags for the same option, or an indication that they 65 are to be copied from the prefix that matched the Match-Prefix. 67 It is possible to instruct routers to create new prefixes by 68 combining the Use-Prefixes in a PCO with some portion of the 69 existing prefix which matched the Match-Prefix. This simplifies 70 certain operations which are expected to be among the most common. 71 For every Use-Prefix, the PCO specifies a number of bits which 72 should be copied from the existing address or prefix which matched 73 the Match-Prefix and appended to the use-prefix prior to configuring 74 the new prefix on the interface. The copied bits are zero or more 75 bits from the positions immediately after the length of the use- 76 prefix. If subnetting information is in the same portion of of the 77 old and new prefixes, this synthesis allows a single Prefix Control 78 Operation to define a new global prefix on every router in a site, 79 while preserving the subnetting structure. 81 Because of the power of the Router Renumbering mechanism, each RR 82 message includes a sequence number and an authenticator to guard 83 against replays. Each elementary RR operation is idempotent and so 84 could be retransmitted for improved reliability, as long as the 85 sequence number is current, without concern about multiple 86 processing. However, non-idempotent combinations of elementary RR 87 operations can easily be constructed and messages containing such 88 combinations could not be safely reprocessed. Therefore, all 89 routers are required to guard against processing an RR message more 90 than once. 92 Possibly a network manager will want to perform more renumbering, or 93 exercise more detailed control, than can be expressed in a single 94 Router Renumbering packet on the available media. The RR mechanism 95 is most powerful when RR packets are multicast, so IP fragmentation 96 is undesirable. For these reasons, each RR packet contains a 97 "Segment Number". All RR packets which have a Sequence Number equal 98 to the highest value seen (for each valid key), and which pass the 99 authentication check, are equally valid and must be processed. 100 However, a router must keep track of the Segment Numbers of RR 101 messages already processed and avoid reprocessing a message whose 102 Sequence Number and Segment Number match a previously processed 103 message. 105 There is a "Dry Run" flag which indicates that all routers should 106 simulate processing of the RR message and not perform any actual 107 reconfiguration. A separate "Report" flag instructs routers to send 108 a Router Renumbering Result message back to the source of the RR 109 Command message indicating the actual or simulated result of the 110 operations in the RR Command message. 112 The effect or simulated effect of an RR Command message may also 113 reported to network management by means outside the scope of this 114 document, regardless of the value of the "Report" flag. 116 3. Definitions 118 3.1. Requirements 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [KWORD]. 124 3.2. Terminology 126 Address 127 This term always refers to a 128-bit IPv6 address [AARCH]. When 128 referring to bits within an address, they are numbered from 0 to 129 127, with bit 0 being the first bit of the Format Prefix. 131 Prefix 132 A prefix can be understood as an address plus a length, the 133 latter being an integer in the range 0 to 128 indicating how many 134 leading bits are significant. When referring to bits within a 135 prefix, they are numbered in the same way as the bits of an 136 address. For example, the significant bits of a prefix whose 137 length is L are the bits numbered 0 through L-1, inclusive. 139 Match 140 An address A "matches" a prefix P whose length is L if the first 141 L bits of A are identical with the first L bits of P. (Every 142 address matches a prefix of length 0.) A prefix P1 with length 143 L1 matches a prefix P2 of length L2 if L1 >= L2 and the first L2 144 bits of P1 and P2 are identical. 146 Prefix Control Operation, Match-Prefix, Use-Prefix 147 These are defined section 2. 149 Matched Prefix 150 The existing prefix or address which matched a Match-Prefix. 152 New Prefix 153 A prefix constructed from a Use-Prefix, possibly including some 154 of the Matched-Prefix. 156 Recorded Sequence Number 157 The highest sequence number found in a valid, authenticated 158 message with a given key MUST be recorded in non-volatile storage 159 along with that key. 161 Note that "matches" is a transitive relation but not reflexive. If 162 two prefixes match each other, they are identical. 164 3.3. Authentication Algorithms 166 All implementations MUST support HMAC-MD5 [HMAC] for authentication. 167 Additional algorithms MAY be supported. 169 4. Message Format 171 There are two types of Router Renumbering messages: Commands, which 172 are sent to routers, and Results, which are sent by routers. The 173 two types of messages are distinguished the ICMPv6 "Code" field and 174 differ in the contents of the "Message Body" field. 176 / / 177 | IPv6 header, extension headers | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 / / 180 | ICMPv6 & RR Header (16 octets) | 181 / / 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 / / 184 | RR Message Body | 185 / / 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 / / 188 | Authentication Data (16 octets for HMAC-MD5) | 189 / / 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Router Renumbering Message Format 194 Router Renumbering messages are carried in ICMPv6 packets with Type 195 = TBA. The RR message consists of 197 An RR header, containing the sequence and segment numbers and 198 information about the authentication key and the location and 199 length of the authentication data within the packet. 201 The RR Message Body, of variable length; 203 The authentication data, with length dependent on the 204 authentication type. For HMAC-MD5, 16 octets. 206 All fields marked "reserved" or "res" MUST be set to zero on 207 generation of an RR message. During processing of the message they 208 MUST be included in the authentication check, but otherwise ignored. 210 All implementations which generate Router Renumbering Command 211 messages MUST support sending them to the All Routers multicast 212 address with Link Local and Site Local scopes, and to unicast 213 addresses of link local and site local formats. All routers MUST be 214 capable of receiving RR messages sent to those multicast addresses 215 and to any of their link local and site local unicast addresses. 216 Implementations SHOULD support sending and receiving RR messages 217 addressed to other unicast addresses. 219 4.1. Router Renumbering Header 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Code | Checksum | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | SegmentNumber | Flags | KeyID | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | AuthLen | AuthOffset | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | SequenceNumber | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Fields: 235 Type TBA, the ICMPv6 type code assigned to Router Renumbering 237 Code 0 = Router Renumbering Command 238 1 = Router Renumbering Result 240 Checksum The ICMPv6 checksum, as specified in [ICMPV6]. The 241 checksum covers the IPv6 pseudo-header and all fields of 242 the RR message from the Type field through the 243 Authentication Data. (For purposes of calculating and 244 verifying the Authentication Data, the ICMPv6 checksum 245 field is considered to be zero.) 247 SegmentNumber 248 An unsigned 8-bit field which enumerates different valid 249 RR messages having the same SequenceNumber and KeyID. 251 Flags A combination of one-bit flags. Six are defined and two 252 bits are reserved. 254 +-+-+-+-+-+-+-+-+ 255 |D|R|A|S|P|E|res| 256 +-+-+-+-+-+-+-+-+ 258 The flags D, R, A and S have defined meanings in an RR 259 Command message. In a Result message they MUST be 260 copied from the corresponding Command. The flags P and 261 E are meaningful only in a Result message and MUST be 262 zero in a Command. 264 D 0 indicates that the router configuration is to be 265 modified; 267 1 indicates a "Dry Run" message: processing is to be 268 simulated and no configuration changes are to be 269 made. 271 R 0 indicates that a Result message MUST NOT be sent 272 (but other forms of logging are not precluded); 273 1 indicates that the router MUST send a Result 274 message upon completion of processing the Command 275 message; 277 A 0 indicates that the Command MUST NOT be applied to 278 interfaces which are administratively shut down; 279 1 indicates that the Command MUST be applied to 280 interfaces regardless of administrative shutdown 281 status. 283 S This flag MUST be ignored unless the router treats 284 interfaces as belonging to different "sites". 285 0 indicates that the Command MUST be applied to 286 interfaces regardless of which site they belong 287 to; 288 1 indicates that the Command MUST be applied only to 289 interfaces which belong to the same site as the 290 interface to which the Command is addressed. If 291 the destination address is appropriate for 292 interfaces belonging to more than one site, then 293 the Command MUST be applied only to interfaces 294 belonging to the same site as the interface on 295 which the Command was received. 297 P 0 indicates that the Result message contains the 298 complete report of processing the Command; 299 1 indicates that the Command message was previously 300 processed (and is not a Dry Run) and the 301 responding router is not processing it again. 302 This Result message will have an empty body. 304 E 0 indicates that no error was encountered suring 305 processing of the Command; 306 1 indicates that an error was encoutered. 308 KeyID An unsigned 16-bit field that identifies the key used to 309 create and verify the Authentication Data for this RR 310 message. If multiple authentication algorithms are 311 supported by the implementation, the choice of algorithm 312 is implicit in the KeyID. 314 AuthLen An unsigned 16-bit field giving the length in octets of 315 the Authentication Data. 317 AuthOffset An unsigned 16-bit offset, measured in octets, from the 318 beginning of the RR message (which is the beginning of 319 the ICMPv6 header) to the beginning of the 320 Authentication Data. The smallest valid value for 321 AuthOffset is 16. 323 SequenceNumber 324 An unsigned 32-bit sequence number. The sequence number 325 MUST be non-decreasing for all messages sent with the 326 same KeyID. 328 4.2. Message Body -- Command Message 330 The body of an RR Command message is a sequence of zero or more 331 Prefix Control Operations, each of variable length. The end of the 332 sequence MAY be located by the AuthOffset field in the RR header. 334 4.2.1. Prefix Control Operation 336 A Prefix Control Operation has one Match-Prefix Part of 24 octets, 337 followed by zero or more Use-Prefix Parts of 32 octets each. 339 4.2.1.1. Match-Prefix Part 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | OpCode | OpLength | Ordinal | MatchLen | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | reserved | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | | 349 +- -+ 350 | | 351 +- MatchPrefix -+ 352 | | 353 +- -+ 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Fields: 359 OpCode An unsigned 8-bit field specifying the operation to be 360 performed when the associated MatchPrefix matches an 361 interface's prefix or address. Values are: 363 1 the ADD operation 365 2 the CHANGE operation 367 3 the SET-GLOBAL operation 369 OpLength The total length of this Prefix Control Operation, in 370 units of 8 octets. A valid OpLength will always be of 371 the form 4N+3, with N equal to the number of UsePrefix 372 parts (possibly zero). 374 Ordinal An 8-bit field which MUST have a different value in each 375 Prefix Control Operation contained in a given RR Command 376 message. 378 MatchLen An 8-bit unsigned integer between 0 and 128 inclusive 379 specifying the number of initial bits of MatchPrefix 380 which are significant in matching. 382 MatchPrefix The 128-bit prefix to be compared with each interface's 383 prefix or address. 385 4.2.1.2. Use-Prefix Part 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | UseLen | KeepLen | Mask | RAFlags | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Valid Lifetime | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Preferred Lifetime | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |V|P| reserved | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | | 399 +- -+ 400 | | 401 +- UsePrefix -+ 402 | | 403 +- -+ 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Fields: 409 UseLen An 8-bit unsigned integer less than or equal to 128 410 specifying the number of initial bits of UsePrefix to 411 use in creating a new prefix for an interface. 413 KeepLen An 8-bit unsigned integer less than or equal to (128- 414 UseLen) specifying the number of bits of the prefix or 415 address which matched the associated Match-Prefix which 416 should be retained in the new prefix. The retained bits 417 are those at positions UseLen through (UseLen+KeepLen-1) 418 in the matched address or prefix, and they are copied to 419 the same positions in the New Prefix. 421 Mask An 8-bit mask. A 1 bit in any position means that the 422 corresponding flag bit in a Router Advertisement (RA) 423 Prefix Information Option for the New Prefix should be 424 set from the RAFlags field in this Use-Prefix Part. A 0 425 bit in the Mask means that the RA flag bit for the New 426 Prefix should be copied from the corresponding RA flag 427 bit of the Matched Prefix. 429 RAFlags An 8 bit field which, under control of the Mask field, 430 may be used to initialize the flags in Router 431 Advertisement Prefix Information Options [ND] which 432 advertise the New Prefix. Note that only two flags have 433 defined meanings to date: the L (on-link) and A 434 (autonomous configuration) flags. These flags occupy 435 the two leftmost bit positions in the RAFlags field, 436 corresponding to their position in the Prefix 437 Information Option. 439 Valid Lifetime 440 A 32-bit unsigned integer which is the number of seconds 441 for which the New Prefix will be valid [ND, SAA]. 443 Preferred Lifetime 444 A 32-bit unsigned integer which is the number of seconds 445 for which the New Prefix will be preferred [ND, SAA]. 447 V A 1-bit flag indicating that the valid lifetime of the 448 New Prefix MUST be effectively decremented in real time. 450 P A 1-bit flag indicating that the preferred lifetime of 451 the New Prefix MUST be effectively decremented in real 452 time. 454 UsePrefix The 128-bit Use-prefix which either becomes or is used 455 in forming (if KeepLen is nonzero) the New Prefix. It 456 MUST NOT have the form of a multicast or link-local 457 address [AARCH]. 459 4.3. Message Body -- Result Message 461 The body of an RR Result message is a sequence of zero or more Match 462 Reports of 24 octets. An RR Command message with the "R" flag set 463 will elicit an RR Result message containing one Match Report for 464 each Prefix Control Operation, for each different prefix it matches 465 on each interface. The Match Report has the following format. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | reserved | Ordinal | MatchedLen | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | InterfaceIndex | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | 475 +- -+ 476 | | 477 +- MatchedPrefix -+ 478 | | 479 +- -+ 480 | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Fields: 485 Ordinal Copied from the Prefix Control Operation whose 486 MatchPrefix matched the MatchedPrefix on the interface 487 indicated by InterfaceIndex. 489 MatchedLen The length of the existing prefix which was matched by 490 the MatchPrefix. 492 InterfaceIndex 493 The router's numeric designation of the interface on 494 which the MatchedPrefix was configured. This SHOULD be 495 the same designation as is used in the SNMP Interfaces 496 group. 498 It is possible for a Result message to be larger than the Command 499 message which elicited it. Such a Result message may have to be 500 fragmented for transmission. 502 4.4. Authentication 504 The authentication covers the following fields, which are to be 505 treated as contiguous data for the purose of computing and verifying 506 the AuthData. 507 The IPv6 source address, 508 The IPv6 destination address, 509 The ICMPv6 and RR Header, 510 The RR Message Body (which may be empty). 512 4.4.1. HMAC-MD5 514 When the key and algorithm associated with the KeyID indicate that 515 HMAC-MD5 authentication is to be used, the AuthData is generated in 516 accordance with RFC 2104 [HMAC]. 518 Before generating the AuthData, all fields of the RR header and all 519 the PCOs are filled in, except that the ICMPv6 checksum field is set 520 to zero. AuthLen will be 16 and AuthOffset will be equal to the 521 length in octets of the RR message, not including the IPv6 header or 522 any extension headers, but including the ICMPv6 header. 524 When checking the AuthData, the ICMPv6 checksum must be set to zero. 526 4.4.2. IPSEC 528 The KeyID value zero is reserved to indicate that no Authentication 529 is done on the Router Renumbering message itself. An RR message 530 with Key ID zero MUST have AuthLen equal to zero and AuthOffset 531 equal to the total length of the ICMPv6/RR header plus the RR 532 message body. Such a message MUST be authenticated at the IP level 533 [IPSEC]. 535 5. Message Processing 537 Processing of received Router Renumbering messages consists of three 538 parts: header check, authentication check, and execution. 540 5.1. Header Check 542 First, the existence and validity of the key indicated by the KeyID 543 are checked. If there is no such valid key, or if the value of 544 AuthLen is not correct for that key, the message MUST be discarded, 545 and SHOULD be logged to network management. 547 Next, the SequenceNumber is compared to the Recorded Sequence Number 548 for the specified key. (If no messages have been received using 549 this key, the Recorded Sequence Number is zero.) This comparison is 550 done with the two numbers considered as unsigned integers, not as 551 DNS-style serial numbers. If the SequenceNumber is less than the 552 Recorded Sequence Number for the key, the message MUST be discarded 553 and SHOULD be logged to network management. 555 If the SequenceNumber in the message is equal to the Recorded 556 Sequence Number, the SegmentNumber MUST be checked. If a correctly 557 authenticated message with the same KeyID, SequenceNumber and 558 SegmentNumber has already been processed, then an RR Result message 559 MUST be sent to the source address of the Command if and only if the 560 R flag is set in the Command. If a Result message is sent, it MUST 561 have the P flag set in the RR header and contain no Match Reports. 562 Then the current message MUST be discarded but SHOULD NOT be logged 563 to network management. 565 Finally, if the router is multi-sited, and the S flag is set and the 566 destination address of the Command is appropriate for interfaces 567 belonging to more than one site, but is not appropriate for the 568 interface on which the Command was received, this is an error. If 569 the R flag is set, return a Result message with the E flag set and 570 no Match Reports. The Command message MUST be discarded and SHOULD 571 be logged to network management. 573 5.2. Authentication Check 575 The authentication check is performed over the RR message, without 576 any IPv6 or extension headers. In the case of HMAC-MD5 it proceeds 577 as described in [HMAC] and [MD5]. If the computed authentication 578 value is not equal to the AuthData in the received packet, the 579 authentication check fails. 581 If the authentication check fails, the message MUST be discarded and 582 SHOULD be logged to network management. 584 If the authentication check passes, and the SequenceNumber is 585 greater than the Recorded Sequence Number for the key, then the list 586 of processed SegmentNumbers, if any, MUST be cleared and the 587 Recorded Sequence Number MUST be updated to the value used in the 588 current message, regardless of subsequent processing errors. 590 5.3. Execution 592 For each applicable router interface, as determined by the A and S 593 flags, the Prefix Control Operations in an RR Command message must 594 be carried out in order of appearance. The order of PCO processing 595 on different interfaces is not specified. 597 If the R flag is set in the RR header, begin constructing an RR 598 Result message. The RR header is completely determined at this time 599 except for the Checksum and AuthOffset. 601 For each interface and for each Prefix Control Operation, each 602 prefix configured on that interface is tested to determine whether 603 it matches (as defined in section 3.2.) the MatchPrefix of the PCO. 604 The prefixes are tested in an arbitrary order. Any new prefix 605 configured on an interface by the effect of a given PCO MUST NOT be 606 tested against that PCO, but MUST be tested against any subsequent 607 PCOs in the same RR Command message. 609 Under a certain condition the addresses on an interface are also 610 tested to see whether any of them matches the MatchPrefix. If and 611 only if a prefix "P" does not match the MatchPrefix "M" but M does 612 match P (this can happen only if M is longer than P), then those 613 addresses on that interface which match P MUST be tested to 614 determine whether any of them matches M. If any such address does 615 match M, process the PCO as if P matched M, but when forming New 616 Prefixes, when KeepLen is non-zero, bits are copied from the 617 address. 619 If P does not match M, processing is finished for this combination 620 of PCO, interface and prefix. Continue with another prefix on the 621 same interface if there are any more prefixes which have not been 622 tested against this PCO and were not created by the action of this 623 PCO. If no such prefixes remain on the current interface, continue 624 processing with the next PCO on the same interface, or with another 625 interface. 627 If P does match M, either directly or because a configured address 628 which matches P also matches M, then P is the Matched Prefix. 629 Perform the following steps. 631 If the Command has the R flag set, add a Match Report to 632 the Result message being constructed. If the D flag is 633 set, processing is now complete for this combination of 634 PCO, interface and prefix. Otherwise, continue with the 635 remaining steps. 637 If the OpCode is CHANGE, mark P for deletion from the 638 current interface. 640 If the OpCode is SET-GLOBAL, mark all global-scope 641 prefixes on the current interface for deletion. 643 If there are any Use-Prefix parts in the current PCO, form 644 the New Prefixes. For each New Prefix which is already 645 configured on the current interface, unmark that prefix 646 for deletion and update the lifetimes and RA flags. For 647 each New Prefix which is not already configured, add the 648 prefix and, if appropriate, configure an address on that 649 prefix. 651 Delete any prefixes which are still marked for deletion, 652 together with any addresses which match those prefixes but 653 do not match any prefix which is not marked for deletion. 655 After succesful processing of all the Prefix Control Operations on 656 all the interfaces, an implementation MUST record the SegmentNumber 657 of the packet in a list associated with the KeyID and 658 SequenceNumber. 660 If the Command has the R flag set, compute the AuthData and append 661 it to the Result message, fill in the AuthOffset and Checksum and 662 send the Result message. 664 6. Key Management 666 As with all security methods using keys, it is necessary to change 667 the RR Authentication Key on a regular basis. To provide RR 668 functionality during key changes, implementations MUST be able to 669 store and use more than one Authentication Key at the same time. 671 The Authentication Keys SHOULD NOT be stored or transmitted using 672 algorithms or protocols that have known flaws. Implementations MUST 673 support the storage of more than one key at the same time, MUST 674 associate a specific lifetime (start and end times) and a key 675 identifier with each key, and MUST support manual key distribution 676 (e.g., manual entry of the key, key lifetime, and key identifier on 677 the router console). 679 An infinite key lifetime SHOULD NOT be allowed. If infinite 680 lifetimes are allowed, manual deletion of valid keys MUST be 681 supported; otherwise manual deletion SHOULD be supported. The 682 implementation MAY automatically delete expired keys. 684 7. Usage Guidelines 686 7.1. Updating Global-Scope Prefixes 688 A simple use of the Router Renumbering mechanism, and one which is 689 expected to to be common, is the maintenance of a set of global 690 prefixes with a subnet structure that matches that of the site's 691 site-local address assignments. 693 7.2. Key Changes 695 Using a new authentication key while a previously used key is still 696 valid can open the possibility of a replay attack. The processing 697 rules as given in section 5. specify that routers keep track of the 698 highest sequence number seen for each key, and that messages with 699 that key and seuence number remain valid until either a higher 700 sequence number is seen or the key expires. The difficulty arises 701 when a new key is used to send a message which supersedes the last 702 message sent with another still-valid key. That older message can 703 still be replayed. 705 This vulnerability can be avoided in practice by sending a "NO-OP" 706 message with the old key and a valid new sequence number before 707 using a newer key. This mesage will then become the only one which 708 can be replayed with the old key. An example of a NO-OP message 709 would be one which contains no Prefix Control Operations. 711 Cearly a management station must keep track of the highest sequence 712 number it has used for each authentication key, at least to the 713 extent of being able to generate a larger value when needed. A 714 timestamp may make a good sequence number. 716 8. Points for Discussion 718 Is there a less colloquial (more nearly i18n-freindly) 719 term for Dry Run, which isn't too wordy and which doesn't 720 start with R, A, or S? 722 The "reserved" field of the Match-Prefix Part could be 723 used to specify another condition in addition to matching 724 a prefix. For example, one of the prefix lifetime timers 725 could be tested against a value. 727 If the messages of several different protocols use the 728 same authentication mechanism then it's possible for one 729 authenticated message body to be grafted onto a different 730 set of headers and cause at least some confusion, and 731 possibly worse. This can be prevented by placing magic 732 numbers or other fixed data in the packets so that a 733 packet for one protocol is never valid for another. 734 Another solution is never to use the same set of keys for 735 two different protocols. 737 Since RR messages will presumably be generated only by a 738 set network management stations which is disjoint from the 739 set of routers to which they are directed, an asymmetric 740 authentication scheme would be desirable. 742 Do we need to specify when it's appropriate for the router 743 to configure an address on a new prefix? And if so, how? 744 (Stateless Auto vs. DHCPv6.) 746 9. Security Considerations 748 The Router Renumbering mechanism proposed here is very powerful and 749 prevention of spoofing it is important. Replay of old messages must 750 be prevented, except in the narrow case of idempotent messages which 751 are still valid at the time of replay. We believe the 752 authentication mechanisms included in this specification achieve the 753 necessary protections, so long as authentication keys are not 754 compromised. 756 Authentication keys must be as well protected as is any other access 757 method that allows reconfiguration of a site's routers. 758 Distribution of keys must not expose them or permit alteration, and 759 key lifetimes must be limited. 761 NOTE: The auth. processing must be changed to include the 762 destination address. May as well include the source address for 763 lagniappe. 765 10. Acknowledgments 767 Some of the key management text was borrowed from "RIP-II MD5 768 Authentication." (And the loan was repaid in kind.) 770 11. References 772 [AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing 773 Architecture", draft-ietf-ipngwg-addr-arch-v2-05.txt. 775 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 776 for Message Authentication", RFC 2104. 778 [ICMPV6]A. Conta, S. Deering, "Internet Control Message Protocol 779 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", 780 currently draft-ietf-ipngwg-icmp-v2-00.txt. 782 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the 783 Internet Protocol", currently draft-ietf-ipsec-arch-sec- 784 02.txt. 786 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 787 Requirement Levels," RFC 2119. 789 [MD5] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321. 791 [ND] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for 792 IP Version 6 (IPv6)", currently draft-ietf-ipngwg- 793 discovery-v2-00.txt. 795 [SAA] S. Thomson, T. Narten, "IPv6 Stateless Address 796 Autoconfiguration", draft-ietf-ipngwg-addrconf-v2-00.txt. 798 12. Authors' Addresses 800 Matt Crawford Robert M. Hinden 801 Fermilab MS 368 Ipsilon Networks, Inc. 802 PO Box 500 232 Java Drive 803 Batavia, IL 60510 Sunnyvale, CA 94089 804 USA USA 806 Phone: +1 630 840 3461 Phone: +1 408 990 2004 808 Email: crawdad@fnal.gov Email: hinden@ipsilon.com