idnits 2.17.1 draft-kitamura-ipv6-record-route-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (17 November 2000) is 8561 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: 'DHop' is mentioned on line 537, but not defined == Unused Reference: 'ICMPv6' is defined on line 652, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT H. Kitamura 2 NEC Corporation 3 Expires in six months 17 November 2000 5 Record Route for IPv6 (RR6) 6 Hop-by-Hop Option Extension 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document proposes a "Record Route for IPv6 (RR6)" mechanism. It 34 is composed of one new IPv6 hop-by-hop option (RR6 option) extension. 36 The RR6 mechanism is redesigned to establish an optimized record 37 route mechanism for IPv6. Two types of new features are introduced. 39 1. In order to prevent scalability problems and to make the mechanism 40 flexible, the beginning and ending points of the data recording range 41 are controlled by using their specifiers. 43 2. In order to record long IPv6 addresses efficiently, a simple 44 address compression method is introduced. Since the compression is 45 achieved by utilizing characteristics of recorded IPv6 addresses 46 effectively, the mechanism is efficient and optimized for IPv6. 48 1. Introduction 50 This document proposes a "Record Route for IPv6 (RR6)" mechanism. It 51 is composed of one new IPv6 Hop-by-Hop option (RR6 option) extension. 53 In the IPv6 specifications [IPv6], no record route function is 54 defined, and the record route function for IPv4 is less flexible and 55 has scalability problems. 57 The RR6 mechanism is redesigned to establish an optimized record 58 route mechanism for IPv6 and fix the problems of the record route 59 function for IPv4. Two types of new features are introduced to 60 achieve this goal. 62 1. In order to prevent scalability problems and to make the mechanism 63 flexible, the beginning and ending points of the data recording range 64 are controlled by using their specifiers. 66 2. In order to record long IPv6 addresses efficiently, a simple 67 address compression method is introduced. Since the compression is 68 achieved by utilizing characteristics of recorded IPv6 addresses 69 effectively, the mechanism is efficient and optimized for IPv6. 71 2. Design of the Record Route for IPv6 (RR6) Mechanism 73 Since a record route operation runs on each node along a 74 communication path, it is appropriate to achieve the record route 75 operation as a hop-by-hop option operation. One IPv6 hop-by-hop 76 option (RR6 option) is introduced to establish the RR6 mechanism. 78 2.1 Roles of the RR6 Option Operations 80 The RR6 option has the following roles. 82 1. Provide Data Storing Space 84 A Data Space is prepared in the RR6 option header. All of the data 85 recorded by the RR6 option operation is written into the Data 86 Space in the RR6 option header. 88 Changing the length of the packet on an intermediate node makes 89 the mechanism complex, so that the length of the Data Space is not 90 changed by the RR6 address data recording operations on each node. 91 When the packet in which the RR6 option is set is prepared for 92 sending, the Data Space is preallocated in it. 94 (Since the length of the Data Space is limited, the data recording 95 or carrying capacity of one packet in which the RR6 option is set 96 is limited. This scalability issue is discussed in Section 2.2) 98 2. Record Address Information 100 When a packet in which the RR6 option is set passes through nodes 101 along the communication path, the RR6 option operation routine on 102 each node records (incoming interface's) address information of 103 the node. The address information is written into the Data Space 104 in the RR6 option header. 106 Exception: 107 On the source node, outgoing interface's address information of 108 the source node is recorded. 110 3. Carry the Recorded Data 112 The recorded data is carried by packets in which the RR6 option is 113 set. This is easy to achieve, because the Data Space exists in the 114 RR6 option header. 116 (Since recorded data is normally analyzed on a source node that 117 issues the packet in which RR6 option is set, the recorded data 118 must be carried back to the source node. Namely, the RR6 option 119 must be set to the packet that returns to the source node. This 120 issue is discussed in Section 2.4) 122 2.2 Data Recording Range Control 124 Since the length of the Data Space is limited, the data recording or 125 carrying capacity of one packet in which the RR6 option is set is 126 limited. 128 To prevent scalability problems and to make the mechanism flexible, 129 the beginning and ending points (nodes) of data recording range are 130 controlled by using their specifiers. 132 When a packet in which the RR6 option is set can not record or carry 133 all of address information of nodes along the communication path 134 (because the number of nodes is larger than the capacity), an 135 additional packet(s) whose data recording beginning point specifier 136 is set appropriately is issued and the remaining address information 137 is recorded and carried by it. 139 This RR6 mechanism does not cause any scalability problems. Details 140 of the data recording range control are explained in Section 3.3. 142 2.3 Address Recording with Compression 144 The maximum length of one hop-by-hop option is 255 octets, and the 145 IPv6 address is long in length (16 octets). If address information is 146 recorded as a plain (non-compressed) address format, one hop-by-hop 147 option can record and carry only 15 record entries. 149 When the RR6 mechanism is applied to a large-scale network 150 environment, 15 entries are insufficient. Thus, it is necessary to 151 provide a compressed address recording method. 153 It is requested that a compressed address recording method of the RR6 154 mechanism must be sufficiently simple and efficient, because the RR6 155 mechanism is achieved as a hop-by-hop option operation that runs on 156 each node along the communication path. A complex and heavy operation 157 is not suitable for the compressed address recording method. 159 A series of recorded addresses is composed of successive neighbor 160 addresses, and is not a series of random numbers. It is strongly 161 assumed that each address is correlated with its previous or 162 succeeding address in the series. In other words, two neighboring 163 addresses will have the same leading part (prefix). This special 164 characteristic can be used for a simple and efficient address 165 compression method. 167 Generally speaking, compression methods are categorized into two 168 types, intra-compression and inter-compression. 170 Since inter-compression methods work efficiently for a series of 171 successive neighbor addresses, the RR6 mechanism adopts one of the 172 inter-compression methods to achieve a compressed address recording 173 mechanism. Details are explained in Section 3.3, 175 2.4 Loop Communication Path 177 Since recorded data is normally analyzed on a source node that issues 178 a packet in which the RR6 option is set, the recorded data must be 179 carried back to the source node. Namely, the RR6 option must be set 180 to the packet that returns to the source node. 182 There are two ways of making a loop communication path. 184 One is to utilize an ICMPv6 Echo Request/Reply (ping6) mechanism. 186 In order to run the RR6 mechanism appropriately on the ping6 187 mechanism, the following two operations must be implemented on the 188 ping6's target node. 190 1. All of the RR6 option fields must be copied from 191 an Echo Request message to an Echo Reply message. 193 2. The Hop Limit field of the IPv6 header of these messages 194 must be copied as a continuous sequence. 196 The other is to prepare a packet in which a Route option is set. 198 The source node must be set to the final destination of the Route 199 option, and the target node must be set to one of the intermediate 200 nodes that are specified in the Route option. 202 No special operations are required to run the RR6 mechanism in 203 this method. 205 3. Record Route for IPv6 (RR6) Option Format: IPv6 Hop-by-Hop Option 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Option Type | Opt Data Len | RR6_Type | Rec_Pointer | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Begin_Hop_L | End_Hop_L | Reserved | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 212 | | 213 | | 214 | Data Space | 215 | | 216 | | 218 Option Type: 8-bit. 219 Identifier of the type of option (RR6 option) 220 Value is 001xxxxx. 0x20+TBA 221 (Tentatively 0x23) 223 RR6 Option Type must be started as 00 to avoid 224 discarding the packet at the RR6 feature disabled 225 node, and the third bit must be set to 1 to record 226 data into the [Data Space]. 227 [see Section 4.2 of RFC2460] 229 Opt Data Len: 8-bit unsigned integer. 230 Length of the [Option Data] field of this option 231 Max: 255 232 Depends on the length of [Data Space] 234 RR6_Type: 8-bit. 235 Identifier of the data recording type 237 =0 Plain (non-compressed) address record type 238 [see Section 3.2] 239 =1 Compressed address record type 240 [see Section 3.3] 242 Rec_Pointer: 8-bit unsigned integer. 243 Pointer that shows next data recording point 244 in the [Data Space] in octet 246 Initial: 0 247 Data recording status can be checked by Rec_Pointer 248 (=0 means that no data has been recorded yet) 250 Begin_Hop_L: 8-bit unsigned integer. 251 Data recording beginning point specifier 252 (In a model case, it shows Hop Limit value of 253 the node that begins the data recording on the path) 255 default: 255 256 [see Section 3.1] 258 End_Hop_L: 8-bit unsigned integer. 259 Data recording ending point specifier 260 (In a model case, it shows Hop Limit value of 261 the node that ends the data recording on the path) 263 default: 0 265 End_Hop_L has another role to indicate that 266 [Data Space] is filled on the communication path. 268 When it is detected that [Data Space] is fully filled 269 and there is no space left to record new data, 270 [End_Hop_L] is set with the Hop Limit value of the 271 last data record node. 272 [see Section 3.1] 274 Reserved: 8-bit. (Reserved Octet) 275 Reserved octet for future use. 277 Data Space: [Opt Data Len]-5 octets 278 Buffer space to record the address information data. 280 Length of [Data Space] must be longer than or 281 equal to 17 (length of one fixed length record). 283 3.1 Procedure of Data Recording Range Control 285 As described in Section 2.2, the data recording range can be 286 controlled by specifying the data recording beginning and ending 287 points. Begin_Hop_L and End_Hop_L are used to specify these points. 289 When a packet the RR6 option is set passes through a node, the 290 current Hop Limit value (Hop_L) of the node is initially compared 291 with Begin_Hop_L and End_Hop_L. If Hop_L is located between them, an 292 address recording operation is started. 294 End_Hop_L has another role. If the Data Space is fully filled on an 295 intermediate node on the communication path, End_Hop_L is set with 296 the Hop Limit value of the last data record node to indicate its 297 location. 299 The following describes an algorithm of data recording range control. 301 while (Begin_Hop_L >= Hop_L && Hop_L >= End_Hop_L) { 302 Prepare a data record to write into the Data Space; 303 // Check the remaining space in the Data Space 304 if (there is enough space to record address information) { 305 Record the prepared data record into the Data Space; 306 if (Data Space has been fully filled without odd remains) { 307 End_Hop_L is set by the Hop Limit value of the current node; 308 } 309 } else { // there is no space left to record new data 310 End_Hop_L is set with the Hop Limit value of 311 the last (previous) data record node; 312 // End_Hop_L = Prev_Rec_HopL; 313 // in the compressed address record type [see Section 3.3] 314 } 315 } 317 3.1.1 Example of Data Recording Range Control 319 Examples of data recording range control behavior are shown here. 321 INI: Hop Limit value of the source node that issues a packet 322 [Source]-[Node1]-[Node2]-[Node3]-[Node4]-[Node5]-... 323 Hop Limit value INI INI-1 INI-2 INI-3 INI-4 INI-5 ... 324 (ex. INI=64) 64 63 62 61 60 59 ... 325 default (w/o Cont.) x x x x x x ... 326 (Begin=(64=INI)) 327 w/ Record Range Cont. - - - x x x ... 328 (ex. Begin=61) 329 w/ Record Range Cont. - - x x x - ... 330 (ex. Begin=62, End=60) 332 3.2 Plain (Non-Compressed) Address Record Type 334 In this section, a plain (non-compressed) address record type is 335 explained. 337 When [RR6_Type] = 0, a plain (non-compressed) address record type is 338 used to record address information. 340 This record type is the simplest method to record address information 341 into the [Data Space]. Address information of a node is recorded as 342 plain format (without compression). 344 Each node provides one data record that contains address information. 345 The length of the data record is fixed (17 octets). When a packet in 346 which the RR6 option is set passes through a node, one data record 347 space is consumed in the [Data Space]. 349 The following is the format of one fixed-length data record. 351 +-+-+-+-+-+-+-+-+ 352 | Hop_Lim_A | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 | Address of Node A (16 octets) | 356 | (Hop_Lim_A= Hop Limit of Node A) | 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 One fixed-length data record comprises the Hop Limit (1 octet) and 361 the (incoming interface's) address (16 octets) information of the 362 node. 364 Hop Limit information of the node is used to identify the location on 365 the communication path. 367 Exception: 369 If [Begin_Hop_L] >= Hop Limit value of the source node, the source 370 node must record its address information. Since there is no incoming 371 operation on the source node, outgoing interface's address 372 information is recorded into the [Address of Node] field instead of 373 incoming interface's address information. 375 3.2.1 Example of Data-Filled Format (Plain Address Record Type) 377 The following shows an example of how the [Data Space] is filled with 378 fixed-length data records. 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Option Type | Opt Data Len | RR6_Type=0 | Rec_Pointer | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Begin_Hop_L | Max_Records | Reserved | Hop_Lim_A | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | 386 | Address of Node A (16 octets) | 387 | (Hop_Lim_A= Hop Limit of Node A) | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Hop_Lim_B | | 391 +-+-+-+-+-+-+-+-+ | 392 | Address of Node B (16 octets) | 393 | (Hop_Lim_B= Hop Limit of Node B) | 394 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | Hop_Lim_C | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 397 | Address of Node C (16 octets) | 398 | (Hop_Lim_C= Hop Limit of Node C) | 399 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | Hop_Lim_D | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 402 | Address of Node D (16 octets) | 403 | (Hop_Lim_D= Hop Limit of Node D) | 404 | +-+-+-+-+-+-+-+-+ 405 | | | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 407 | | 408 | | 410 Some nodes on the communication path do not record address 411 information for some reason (e.g., not implementing or intentionally 412 disabling the RR6 feature). 414 Thus, Node A, B, C, D, ... are not always successive neighbor nodes, 415 and Hop_Lim_A, Hop_Lim_B, Hop_Lim_C, Hop_Lim_D, ... are not always 416 consecutive descending numbers. 418 3.3 Compressed Address Record Type 420 In this section, a compressed address record type is explained. 422 (This document defines one simple and efficient compressed address 423 record type. Since there are various address compression methods, 424 other compressed address record types may be proposed in other 425 documents in future). 427 When [RR6_Type] = 1, a compressed address record type is used to 428 record address information. 430 Address information of a node is recorded into the [Data Space] as a 431 compressed format. Each node provides one data record. Since address 432 information is compressed, the length of the record is variable (max 433 17 octets). When the packet in which the RR6 option is set passes 434 through a node, its RR6 operation consumes one variable-length data 435 record space in the [Data Space]. 437 3.3.1 Compression Method 439 Series of recorded addresses have a special characteristic. It is 440 composed of successive neighbor addresses. It is strongly assumed 441 that each address is correlated with its previous or succeeding 442 address in the series. Specifically, it is assumed that two 443 neighboring addresses have the same leading part (prefix). 445 By omitting the same leading part, address information can be 446 compressed. This simple compression method utilizes the special 447 characteristic efficiently, and it is adopted for this record type. 449 (This method is categorized into inter-compression methods. In order 450 to simplify the mechanism, intra-compression methods are not used in 451 this record type.) 453 To establish a simplified compression mechanism, the same leading 454 part is omitted in octet unit (not bit unit). 456 The compression is composed of the following operations. 458 1. Compare current address with previous address. 460 2. Find the same leading part between them in octet 462 3. Omit the same leading part in octet, and calculate the length 463 of the remaining part of the current address information. 465 3.3.2 Data Space Format Extension for Compressed Address Record Type 467 In order to compare current and previous information, the leading 17 468 octets of the [Data Space] are used to keep Hop Limit and Address 469 information of the previous (last data recorded) node. 471 The following format is used in the compressed address record type. 472 (This format is an upper compatible format from the basic RR6 format) 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Option Type | Opt Data Len | RR6_Type=1 | Rec_Pointer | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Begin_Hop_L | End_Hop_L | Reserved | Prev_Rec_HopL | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | | 480 | Previous Record Address | 481 | | 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 | Data Space (for Variable Length Data Records) | 486 | | 488 Prev_Rec_HopL: 8-bit unsigned integer. 489 Hop Limit value of the previous (last data recorded) 490 node 492 Previous Record Address: 16-octet 493 (Incoming interface's) address of the previous 494 (last data recorded) node 496 (If [Begin_Hop_L] >= Hop Limit value of the source node, the source 497 node fills [Prev_Rec_HopL] with Hop Limit value of the source node, 498 fills [Previous Record Address] with outgoing interface's address 499 information of the source node, and sets [Rec_Pointer] with 17) 501 3.3.3 Variable Length Data Record Format 503 The following is a format of one variable-length data record. 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 506 | DHop | Len | Compressed Address 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 509 (Maximum length: 17 octets) 511 DHop: 4bit. 512 Hop difference that is calculated by the following 513 formula [Prev_Rec_HopL] - [Current Hop Limit] 514 (=0 means more than 15 hop difference) 516 Len: 4bit. 517 Length of the following [Compressed Address] 518 (=0 means 16) 520 Compressed Address: 521 Compressed current address 522 (The same leading part in octet is omitted) 524 (Max length 16) 526 Note: 528 In usual cases (hop differences are smaller than 16), [DHop] can show 529 accurate hop difference. Only when some hop difference on the path is 530 larger than 15, a situation ([DHop] = 0) appears in the [Data Space], 531 and this causes a Hop Limit counting ambiguity. 533 If the situation ([DHop] = 0) appears only once in the [Data Space], 534 such an ambiguity can be cleared by checking the initial Hop Limit 535 value and the Hop Limit value of the received packet. 537 If the situation ([DHop] = 0) appears more than once in the [Data 538 Space], such ambiguities are not cleared in the compressed address 539 record type. If it is necessary to count Hop Limit values of nodes 540 accurately, the plain (non-compressed) address record type 541 accompanied with appropriate data recording range control is used. 543 3.3.4 Operation Steps at Each Node 545 1. Prepare a variable-length data record 546 Calculate "DHop", "Compressed Address" and "Len" 548 2. Write the data record into [Data Space (for Variable Length 549 Data Records)]. Writing start point in [Data Space] is 550 indicated by [Rec_Pointer] 552 3. Update [Rec_Pointer] ([Rec_Pointer] += (1+[Len])) 554 4. Update [Prev_Rec_HopL] with Hop Limit value of current node 556 5. Update [Previous Record Address] with address information 557 of current node 559 Note: 561 Only step 4 and 5 are executed on an initial data record node, and no 562 data is recoded into [Data Space (for Variable Length Data Records)]. 564 3.3.5 Example of Data-Filled Format (Compressed Address Record Type) 566 The followings show an example how the [Data Space] is filled with 567 variable-length data records. 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Option Type | Opt Data Len | RR6_Type=1 | Rec_Pointer | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Begin_Hop_L | End_Hop_L | Reserved | Prev_Rec_HopL | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | | 575 | Previous Record Address (16 octets) | 576 | | 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | DHop_A| Len=13| | 580 +-+-+-+-+-+-+-+-+ | 581 | Compressed Address A (13 octets) | 582 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | | DHop_B| Len=12| | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 585 | Compressed Address B (12 octets) | 586 | +-+-+-+-+-+-+-+-+ 587 | | DHop_C| Len=9 | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Compressed Address C (9 octets) | 590 | | 591 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | DHop_D| Len=10| | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 594 | Compressed Address D (10 octets) | 595 | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | 599 4. IANA Considerations 601 The RR6 mechanism has introduced one IPv6 Hop-by-Hop option. In order 602 to implement the RR6 mechanism, one IPv6 Hop-by-Hop option type value 603 is tentatively assigned from unassigned spaces as follows. 605 IPv6 Hop-by-Hop Option: RR6 Type: 0x23 (Tentatively) 607 This number must be assigned by IANA officially. 609 5. Security Considerations 611 Since address information is not secret information of nodes, the 612 Record Route for IPv6 (RR6) mechanism not have any direct impact on 613 Internet infrastructure security. 615 Appendix A. Recorded Hop Limit value of the Node 617 A node deals with two Hop Limit values on it. One is set to receiving 618 packets; the other is set to transmitting packets. The timing when 619 Hop Limit value is changed (decremented) on the node is not clearly 620 defined. It is necessary that which values is appropriate to be 621 recorded by the RR6 option operations. 623 Since the recorded Hop Limit value of the node is used to identify 624 its location on the communication path, it must be unique and 625 different from Hop Limit values of other nodes on the path. 627 The initial Hop Limit value is not decremented on the source node, so 628 that the initial Hop Limit value is adopted for the recorded Hop 629 Limit value of the source node. Thus, the first node (succeeding node 630 from the source node on the path) can not use the initial Hop Limit 631 value, and the decremented initial Hop Limit value is adopted for the 632 recorded Hop Limit value of the first node. 634 Therefore, the rule is inductively defined. The recorded Hop Limit 635 value of the node is the Hop Limit value that is set to transmitting 636 (outgoing) packets. In other words, the decremented Hop Limit value 637 that is set to receiving (incoming) packets is used for the recorded 638 Hop Limit value of the node. 640 Appendix B. RR6 Implementation 642 The main RR6 operations are implemented at incoming operations (e.g., 643 ip6_input()). Some RR6 operations, however, are implemented at 644 outgoing operations (e.g., ip6_output()), because the RR6 mechanism 645 must run on the source node. 647 References 649 [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 650 Specification," RFC2460, December 1998. 652 [ICMPv6] A. Conta, S. Deering, "Internet Control Message Protocol 653 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 654 Specification," RFC2463, December 1998. 656 Author's Address: 658 Hiroshi Kitamura 659 NEC Corporation 660 Development Laboratories 661 (Igarashi Building 4F) 11-5, Shibaura 2-Chome, 662 Minato-Ku, Tokyo 108-8557, JAPAN 664 Phone: +81 (3) 5476-1071 665 Fax: +81 (3) 5476-1005 666 Email: kitamura@da.jp.nec.com