idnits 2.17.1 draft-thubert-6man-reverse-routing-header-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 10, 2010) is 4886 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) == Unused Reference: 'RFC2119' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC2402' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 809, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-6man-rpl-routing-header-01 == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-01 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-16 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** Downref: Normative reference to an Informational RFC: RFC 3232 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track December 10, 2010 5 Expires: June 13, 2011 7 Reverse Routing Header 8 draft-thubert-6man-reverse-routing-header-01 10 Abstract 12 For new classes of devices such as highly constrained nodes, forward 13 and return Record Route capabilities are required to enable basic 14 forwarding operations. This memo defines a such a technique for 15 IPv6. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 13, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. Flooding downwards . . . . . . . . . . . . . . . . . . . . 7 56 3.2. Following an implicit upwards path . . . . . . . . . . . . 9 57 3.3. Recording a forward path . . . . . . . . . . . . . . . . . 11 58 4. New Routing Headers . . . . . . . . . . . . . . . . . . . . . 13 59 4.1. FRRH and RRH formats . . . . . . . . . . . . . . . . . . . 13 60 4.2. Optimum number of slots . . . . . . . . . . . . . . . . . 14 61 5. Source Routing Node Operation . . . . . . . . . . . . . . . . 17 62 5.1. Processing of ICMP "RRH Warning" . . . . . . . . . . . . . 17 63 5.2. Processing of ICMP error . . . . . . . . . . . . . . . . . 17 64 5.3. Processing of RRH Packets . . . . . . . . . . . . . . . . 17 65 5.4. Processing of FRRH Packets . . . . . . . . . . . . . . . . 18 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 67 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 68 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 21 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 71 10.1. informative reference . . . . . . . . . . . . . . . . . . 23 72 10.2. normative reference . . . . . . . . . . . . . . . . . . . 23 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 1. Introduction 77 This document assumes that the reader is familiar with the IPv6 RH0 78 operation as specified in [RFC2460] and the RH2 as previously defined 79 in [RFC3775] and the RH4 defined for RPL [I-D.ietf-roll-rpl] in 80 [I-D.ietf-6man-rpl-routing-header]. It is more specifically 81 targetted to address the needs of the RPL extensions defined in 82 Reactive Discovery of Point-to-Point Routes [I-D.ietf-roll-p2p-rpl]. 84 This specification defines a Forward Record Routing Header (FRRH), 85 that is a controlled variant of the Loose Source and Record Route 86 (LSRR) defined for IPv4 in [RFC0791] and hereby adapted for IPv6. 87 FRRH records the path of a packet within a closed Source Routing 88 Domain (SRD) such as a RPL network. 90 This specification also introduces a new Routing Header, called the 91 Reverse Routing Header (RRH), to perform source routing within the 92 RPL network along the way back. As opposed to the FRRH that records 93 a forward path, RRH stacks the route bottom up and can be trivially 94 converted into a RH4 to force packets to follow an identical reverse 95 path within the same RPL network. 97 The FRRH and the RRH are designed to be trivially converted into a 98 RH4 to force further packets to follow an identical path within the 99 same RPL network, so the rules that govern the construction of a 100 Routing Header type 4 in [I-D.ietf-6man-rpl-routing-header] also 101 apply similarily to FRRH and RRH. 103 1.1. Motivations 105 A Low Power Lossy Network (LLN) often forms a dynamic NBMA Subnetwork 106 of devices that might be so constrained in memory that they cannot 107 hold all the states that would be required to route within their own 108 Subnetwork. In some instances, default routes to some border routers 109 can be maintained, but the way back to specific destination cannot. 110 In other instances, even the route to the border router will be lost 111 rapidly. 113 RPL [I-D.ietf-roll-rpl] is a Subnetwork Gateway Protocol (SGP), that 114 is a routing protocol that can build and maintain a routing topology 115 within a subnet as well as distribute some subnet information. RPL 116 is optimized for Point to Multipoint (P2MP) from a root and 117 Multipoint to Point (MP2P) to a root of the LLN, but allows a stretch 118 for any to any communication. [I-D.ietf-roll-p2p-rpl] extends RPL to 119 establish on-demand an arbitrary Point to Point (P2P) path with 120 lesser stretch and lower set up and repair latency than the base 121 protocol. This specification allows to locate the additional states 122 at the end-points so as to avoid extra in the intermediate nodes. 124 With strict source routing, the intermediate nodes find the next hop 125 for a given packet in a routing header that is set by the source as 126 specified for instance in [I-D.ietf-6man-rpl-routing-header] that 127 defines the RH type 4 for IPv6. With this specification, the path 128 information in the RH4 is maintained with consistent snapshots of the 129 full path across the Source Route Domain that is recorded in-band 130 with selected packets. 132 2. Terminology 134 This document assumes that the reader is familiar with ROLL 135 terminology defined in [I-D.ietf-roll-terminology]. 137 Additional terms are defined hereafter: 139 DAG Directed Acyclic Graph. 141 SRN Source Routing Node. A host or a router with the capability to 142 support this specification and make use of RRH within its NBMA 143 Subnetwork . 145 SRD Source Routing Domain. A domain in which the Source Route 146 operation is accepted. All intermediate addresses within the same 147 RH must belong to the same SRD. A domain can be: 149 * A node or a contiguous set of nodes such as a dominating set 151 * A Subnetwork such as a RPL Network 153 * A network serving the same Unique Local Aggregation. 155 SRA: Source Routable Address. An address that can be inserted in a 156 RH/RRH. An SRA is an Ipv6 address that belongs to the SR domain 157 with a scope that is valid across the SR domain. 159 TA: Target Address. The last Address in the Routing Header 160 identifying the target. There is no constraint on that address. 162 CRH: Constrained Routing Header. A constrained routing header is a 163 routing header that can be forwarded only within an SRD. It is 164 formed of a list of SRA, followed by at most one TA. 166 FRRH: Forward Record Routing Header, defined in this specification; 167 a variable size record route header used to learn a path hop-by- 168 hop. It is preferably formed of addresses that are located on the 169 ingress interface of the packets. 171 RRH: Reverse Routing Header, defined in this specification; a 172 variable size reverse route header used to learn a path back hop- 173 by-hop. It is formed of addresses that are located on the egress 174 interface of the packets. 176 NULL RH: An FRRH or an RRH with a zero "Segments Used". 178 3. Examples 180 For the sake of the example, the RPL Network in the following figure 181 assumes the logical shape of a tree towards a border router. This 182 abstraction is chosen because it is simpler to represent than the 183 actual Directed Acyclic Graph shape that most RPL Networks will form. 185 +---------------------+ 186 | Internet |---CN 187 +---------------|-----+ 188 Border Router 189 | 190 ======?====== 191 SRN1 192 | 193 ====?=============?==============?=== 194 SRN5 SRN2 SRN6 195 | | | 196 =========== ===?========= ============= 197 SRN3 198 | 199 ===========?== 200 RPL Network SRN4 201 | 202 ========= 204 A tree shaped RPL network 206 This example focuses on a SRD node at depth 3 identified as Source 207 Routing Node 3 (SRN3). The path to the border router and then the 208 Internet is 210 SRN3 -> SRN2 -> SRN1 -> Border Router ->Internet 212 In one example, the Border Routers first initiates a multicast 213 flooding to build a Reverse Routing Header that records the source 214 route path from each node towards itself. In another example, a node 215 that wishes to be reachable starts a record route towards the border 216 router. 218 A node that wishes to be reachable inserts a reverse routing header 219 with a number of N pre-allocated slots that derive from its 220 estimation of its depth. 222 3.1. Flooding downwards 224 In this example, no preexisting routing structure exists and the 225 routing header is being assembled by a flooding mechanism from the 226 Border Router (BR) downwards. 228 The packet has source an IPv6 address of the Border Router Address, 229 BR_Add, and destination a multicast link scope address that is used 230 for the flooding: 232 +-------+-------++ -- ++----+-------++-------+--------+--------+ +--- 233 | SRC | DST |: :| | slotN || slot2 | slot1 | source | | 234 | BR |all XXX|: EXT:|RRH | || | BR | BR | | NH 235 | Add |L scope|: :| | || | SRA | TA | | 236 +-------+-------++ -- ++----+-------++-------+--------+--------+ +--- 238 The BR-SRA acts as locator and it is possible that this address has a 239 limited reach such as ULA. The BR-TA is a global identifier for the 240 BR. It might be omitted when the source of the RRH is only used as 241 an intermediate router and not as a destination. 243 It must be noted that BR-SRA is preferably an address on the BR 244 interface towards SRN1, that is directly visible from SRN1, in case 245 there is no routing between BR and SRN1. 247 BR-SRA is also preferably an address that has a scope as large as the 248 Source Route Domain, enabling the hop-by-hop recording process to 249 possibly omit tracing some intermediate hops and thus form a loose 250 source route header. 252 The routers one hop away figure the best message they receive and 253 propagate it, including the augmented RRH. 255 For SRN1, this gives: 257 +-------+-------++ -- ++----+-------++-------+--------+--------+ +--- 258 | SRC | DST |: :| | slotN || slot2 | slot1 | source | | 259 | SRN1 |all XXX|: EXT:| RRH| || SRN1 | BR | BR | | NH 260 | Add |L scope|: :| | || SRA | SRA | TA | | 261 +-------+-------++ -- ++----+-------++-------+--------+--------+ +--- 263 When SRN3 gets the packet, it receives: 265 +-------+-------++ -- ++----++-------+-------+--------+--------+ +--- 266 | SRC | DST |: :| || slot3 | slot2 | slot1 | source | | 267 |SRN2 |all XXX|: EXT:| RRH|| SRN2 | SRN1 | BR | BR | | NH 268 |Add |L scope|: :| || SRA | SRA | SRA | TA | | 269 +-------+-------++ -- ++----++-------+-------+--------+--------+ +--- 270 The RH4 is trivially built by picking the tail of the incoming RRH, 271 to be inserted when sending a packet to the border router. 272 Additionally, the node might create a tunnel interface towards the 273 border and install a default route there. 275 So an arbitrary destination in the Internet can replace the BR TA and 276 will cause a packet flow like this: 278 transport mode (1 slot consumed if SRN3 TA is included)): 279 +-------+-------+----+-------+-------+-------+---------++ -- + +--- 280 | SRC | DST | RH | slot3 | slot2 | slot1 | destin. |: : | 281 |SRN3 |SRN2 |type| SRN3 | SRN1 | BR | arbitr. |: EXT: | NH 282 |SRA |SRA | 4 | TA | SRA | SRA | destin. |: : | 283 +-------+-------+----+-------+-------+-------+---------++ -- + +--- 285 tunnel mode (nothing consumed): 286 +-------+-------+----+-------+-------+ +-------+-------++ -- + +--- 287 |oSRC |oDST | RH | slot1 | slot0 | |iSRC |iDST |: : | 288 |SRN3 |SRN2 |type| SRN1 | BR | |SRN3 |arbitr.|: EXT: | NH 289 |SRA |SRA | 4 | SRA | SRA | |TA |destin.|: : | 290 +-------+-------++--++-------+-------+ +-------+-------++ -- + +--- 292 Message going out of SRN3 to the BR 294 That reaches the Border Router as this: 296 transport mode (consumed up to slot 1): 297 +-------+-------+----+-------+-------+-------+---------++ -- + +--- 298 | SRC | DST | RH | slot3 | slot2 | slot1 | destin. |: : | 299 |SRN3 |BR |type| SRN3 | SRN2 | SRN1 | arbitr. |: EXT: | NH 300 |TA |SRA | 4 | SRA | SRA | SRA | destin. |: : | 301 +-------+-------+----+-------+-------+-------+---------++ -- + +--- 303 tunnel mode (all consumed): 304 +-------+-------+----+-------+-------+ +-------+-------++ -- + +--- 305 |oSRC |oDST | RH | slot1 | slot0 | |iSRC |iDST |: : | 306 |SRN3 |BR |type| SRN2 | SRN1 | |SRN3 |arbitr.|: EXT: | NH 307 |SRA |SRA | 4 | SRA | SRA | |TA |destin.|: : | 308 +-------+-------++--++------+-------+ +-------+-------++ -- + +--- 310 Message going out of BR: 311 +-------+-------++ -- + +--- 312 | SRC | DST |: : | 313 |SRN3 |arbitr.|: EXT: | NH 314 |TA |destin.|: : | 315 +-------+-------++ -- + +--- 317 Message coming in the border router from SRN3 319 Upon decapsulation, it is up to the border router to decide by policy 320 whether it should route the packet or not. In particular in 321 Transport mode, security reasons might dictate to drop the packet. 323 3.2. Following an implicit upwards path 325 In this example, a preexisting routing structure exists that leads to 326 a well-known border router. The RRH is assembled along that path. 328 The last (bottom) slot contains a global identifier for the SRN, SRN3 329 TA. there is no constraint with regard to the type of IPv6 address 330 used there. It might be omitted if SRN3 uses its SRA to terminate 331 its connections. Then SRN3 inserts its SRA in the slot directly 332 above. 334 The IPv6 header in the packet has source SRN3's Address, SRN3_Add, 335 and destination SRN3's next hop Add, SRN2_Add, on the link between 336 SRN2 and SRN3: 338 +-------+-------++ -- ++----+-------++-------+-------+---------+ +--- 339 | SRC | DST |: :| | slotN || slot2 | slot1 | source | | 340 |SRN3 |SRN2 |: EXT:| RRH| || | SRN3 | SRN3 | | NH 341 |Add |Add |: :| | || | SRA | TA | | 342 +-------+-------++ -- ++----+-------++-------+-------+---------+ +--- 344 The second router on the path, SRN2, receives that the packet. If it 345 is not the border router, then it might wish to propagate the 346 protocol payload towards the border router that is the implicit 347 termination of the propagation as dictated by the protocol operation. 349 The outer packet now has source SRN2 Add and destination SRN1 Add; 350 the RRH from top to bottom is: empty_slots | SRN2_SRA | SRN3_SRA | 351 SRN3_TA: 353 +-------+-------++ -- ++----+-------++-------+-------+---------+ +--- 354 | SRC | DST |: :| | slotN || slot2 | slot1 | source | | 355 |SRN2 |SRN1 |: EXT:| RRH| || SRN2 | SRN3 | SRN3 | | NH 356 |Add |Add |: :| | || SRA | SRA | TA | | 357 +-------+-------++ -- ++----+-------++-------+-------+---------+ +--- 359 In general the process followed by the second router is repeated by 360 all the routers on the path, till the border router that receives and 361 absorbs: 363 +-------+-------++ -- ++----++-------+-------+-------+---------+ +--- 364 | SRC | DST |: :| || slot3 | slot2 | slot1 | source | | 365 |SRN1 |BR |: EXT:| RRH|| SRN1 | SRN2 | SRN3 | SRN3 | | NH 366 |Add |Add |: :| || SRA | SRA | SRA | TA | | 367 +-------+-------++ -- ++----++-------+-------+-------+---------+ +--- 369 When the border router, receives the packet, it MAY store the 370 information in RRH to build an RH4 back to SRN3 TA (or SRN3 SRA if 371 the TA is omitted) 373 Again, the RH is trivially built by picking the trail of the previous 374 RRH, to be inserted by the border router into any packet flowing down 375 to SRN3: 377 Message coming in the border router from the infrastructure behind: 379 +-------+-------++ -- + +--- 380 | SRC | DST |: : | 381 |arbitr.|SRN3 |: EXT: | NH 382 |source |TA |: : | 383 +-------+-------++ -- + +--- 385 Message going out the border router: 387 transport mode: 388 +-------+-------+----+-------+-------+---------++ -- + +--- 389 | SRC | DST | RH | slot2 | slot1 | destin |: : | 390 |arbitr.|SRN1 |type| SRN2 | SRN3 | SRN3 |: EXT: | NH 391 |source |SRA | 4 | SRA | SRA | TA |: : | 392 +-------+-------+----+-------+-------+---------++ -- + +--- 394 Tunnel mode: 395 +-------+-------++----+-------+--------+ +-------+-------++ -- + +--- 396 |oSRC |oDST || RH | slot2 | slot1 | |iSRC |iDST |: : | 397 |SRN3 |SRN1 ||type| SRN2 | SRN3 | |arbitr.|SRN3 |: EXT: | NH 398 |SRA |SRA || 4 | SRA | SRA | |source |TA |: : | 399 +-------+-------++----+-------+--------+ +-------+-------++ -- + +--- 401 The RH type 4 is consumed along the source route path to SRN3 as a 402 deprecated [RFC2460] RH type 0 would, and the last hop (SRN3 SRA to 403 SRN3 TA) is consumed internally in SRN3, if it was present in the 404 first place, like a RH type 2 would be in the case of Mobile IPv6 405 [RFC3775]. 407 3.3. Recording a forward path 409 In this example, a Forward Record RH is filled as the protocol 410 information is propagated along the same upwards path. 412 The FRRH is initially empty. The source SRN3 might virtually start 413 from SRN3-TA in which case that address is added to the FRRH. Then, 414 as any node along the path, SRN3 adds it SRA and passes the packet 415 long. 417 The IPv6 header in the packet has source SRN3's Address, SRN3_Add, 418 and destination SRN3's next hop Add, SRN2_Add, on the link between 419 SRN2 and SRN3: 421 +-------+-------++ -- ++----+-------++-------+-------+-------+ +--- 422 | SRC | DST |: :| | slot0 ||slotn-2|slotN-1| slotN | | 423 |SRN3 |SRN2 |: EXT:|FRRH| SRN3 || | | | | NH 424 |Add |Add |: :| | SRA || | | | | 425 +-------+-------++ -- ++----+-------++-------+-------+-------+ +--- 427 The second router on the path, SRN2, receives that the packet. 428 Again, it might wish to propagate protocol payload towards the border 429 router that is the implicit termination of the propagation. 431 The outer packet now has source SRN2 Add and destination SRN1 Add; 432 the FRRH from top to bottom is SRN3_SRA | SRN2_SRA | empty_slots : 434 +-------+-------++ -- ++----+-------+-------++-------+-------+ +--- 435 | SRC | DST |: :| | slot0 | slot1 ||slotN-1| slotN | | 436 |SRN2 |SRN1 |: EXT:|FRRH| SRN3 | SRN2 || | | | NH 437 |Add |Add |: :| | SRA | SRA || | | | 438 +-------+-------++ -- ++----+-------+-------++-------+-------+ +--- 440 It must be noted that SRN2-SRA is preferably an address on the SRN2 441 ingress interface from SRN3, that is directly visible from SRN3, in 442 case there is no routing between SRN3 and SRN. 444 In general the process followed by the second router is repeated by 445 all the routers on the path, till the border router that receives: 447 +-------+-------++ -- ++----+-------+-------+-------++-------+ +--- 448 | SRC | DST |: :| | slot0 | slot1 | slot2 || slotN | | 449 |SRN1 |BR |: EXT:|FRRH| SRN3 | SRN2 | SRN1 || | | NH 450 |Add |Add |: :| | SRA | SRA | SRA || | | 451 +-------+-------++ -- ++----+-------+-------+-------++-------+ +--- 452 The BR also adds its own information for the internal hop to BR_TA: 454 +-------+-------++ -- ++----+-------+-------+-------+-------++ +--- 455 | SRC | DST |: :| | slot0 | slot1 | slot2 | slot3 || | 456 |SRN1 |BR |: EXT:|FRRH| SRN3 | SRN2 | SRN1 | BR || | NH 457 |Add |Add |: :| | SRA | SRA | SRA | SRA || | 458 +-------+-------++ -- ++----+-------+-------+-------+-------++ +--- 460 At this point, the BR possesses a source route path that is usable 461 from any address along that path back to the BR. It may trivially 462 transform the FRRH into a completed RRH and pass it back to SRN3. 463 SRN3 may then transform the RRH into a RH type 4 and send further 464 packets along the same path. 466 4. New Routing Headers 468 This draft introduces new loose source and record Constrained Route 469 Headers for IPv6. The headers have the same format decribed below 470 and only differ from the Routing type. 472 4.1. FRRH and RRH formats 474 The FRRH and the RRH share the same overall format as the RH4 as 475 defined in [I-D.ietf-6man-rpl-routing-header], with the same 476 contraints: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | CmprI | CmprE | Pad | Reserved | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | | 486 . . 487 . Addresses[1..n] . 488 . . 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Next Header 494 8-bit selector. Identifies the type of header immediately 495 following the Routing header. Uses the same values as the IPv4 496 Protocol field [RFC3232]. 498 Hdr Ext Len 500 8-bit unsigned integer. Length of the Routing header in 8-octet 501 units, not including the first 8 octets. Hdr Ext Len MUST NOT 502 exceed RH4_MAX_SIZE / 8. Note that when Addresses[1..n] are 503 compressed (i.e. value of CmprI or CmprE is not 0), Hdr Ext Len 504 does not equal twice the number of Addresses. 506 Routing Type 508 8-bit unsigned integer. Set (tentatively) to 3 for FRRH and 5 for 509 RRH. 511 Segments Left 513 8-bit unsigned integer. Number of route segments remaining. 515 CmprI 517 4-bit unsigned integer. Number of prefix octets from each 518 segment, except than the last segment, that are elided. For 519 example, a (F)RRH header carrying full IPv6 addresses in 520 Addresses[1..n-1] sets CmprI to 0. 522 CmprE 524 4-bit unsigned integer. Number of prefix octets from the segment 525 that are elided. For example, (F)RRH carrying a full IPv6 address 526 in Addresses[n] sets CmprE to 0. 528 Pad 530 4-bit unsigned integer. Number of octets that are used to for 531 padding after Address[n] and the end of the (F)RRH. 533 Reserved 535 32-bit reserved field. Initialized to zero for transmission; 536 ignored on reception. 538 Address slot [] 540 Vector of 128-bit addresses, numbered 0 to N in LRRH and N to 0 in 541 RRH. 543 4.2. Optimum number of slots 545 A SRN always initializes the number of slots in the F/RRH to the 546 maximum of DEF_RRH_SLOTS and its estimation of its depth, if the 547 latter is known from a reliable hint such as a routing protocol. The 548 message may have a number of unused (NULL) slots, when it is received 549 by the Border Router. The receiver end point crops out the extra 550 entries in order to generates a RH. 552 From a RRH, the receiver generates a RH type 4 that it can use for 553 a response back. 555 From a FRRH, the receiver generates a RRH that is fully consumed, 556 and send that back to the sender which in turn will generate a RH 557 type 4. None of those operations need to change the order of the 558 slots in the header and are mostly plain copies. 560 The RH type 4 contains the number of required slots that the SRN now 561 uses until it gets a hint that the topology changes or until the next 562 route recording. 564 When a node adds its address either to an FRRH or an RRH, it MUST 565 ensure that it owns none of the addresses that are already present in 566 the packet. If it does, then the packet is following a loop. The 567 node drop the packet, or alternatively it may strip the loop from the 568 RH and keep forwarding via an alternate next hop. In that case, it 569 will decrement the Hop limit as usual, to ensure that a loop is 570 ultimately terminated. 572 The number of slots in the RRH MUST NOT be larger than MAX_RRH_SLOTS. 573 If a SRN is deeper than MAX_RRH_SLOTS, it is expected that the rest 574 of the way is already known ot the endpoint. 576 In runtime, it may happen that the RRH has fewer slots than required 577 for the number of SRNs in the path because either the NBMA Subnetwork 578 topology is changing too quickly, or the SRN that inserted the RRH 579 had a wrong representation of the topology. 581 To solve this problem a new ICMP message is introduced, "RRH 582 Warning", type (proposed) 64. A SRN on the upwards path that gets a 583 packet without a free slot in the F/RRH MAY send that ICMP "RRH 584 warning" back to the SRN that inserted the RRH in the first place. 586 This message allows a SRN on the path to propose a larger number of 587 slots to the SRN that creates the RRH. The Proposed Size MUST NOT be 588 larger than MAX_RRH_SLOTS. The originating SRN must rate-limit the 589 ICMP messages to avoid excessive ICMP traffic in the case of the 590 source failing to operate as requested. 592 The originating SRN must insert an RH type 4 based on the F/RRH in 593 the associated IP header, in order to route the ICMP message back to 594 the source of the reverse tunnel. A SRN that receives this ICMP 595 message is the actual destination and it MUST NOT forward it to the 596 source of the packet if the tunnel mode is being used. 598 The "RRH Warning" ICMP has the following format: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type = 64 | Code | Checksum | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Current Size | Proposed Size | Reserved | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | As much of invoking packet headers | 608 + as will fit without the ICMPv6 packet + 609 | exceeding the minimum IPv6 MTU | 610 . . 611 . . 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Type 616 64 [To Be Assigned] 618 Code 1: RRH too small; 2: Loop detected. 620 The originating SRN requires the source to set the RRH size to a 621 larger value. The packet that triggered the ICMP will still be 622 forwarded by the SRN, but the path cannot be totally optimized 623 (see Section 5.3). 625 Checksum 627 The ICMP checksum [RFC2463]. 629 Current Size 631 RRH size of the invoking packet, as a reference. 633 Proposed Size 635 The new value, expressed as a number of IPv6 addresses that can 636 fit in the RRH. 638 Reserved 640 16-bit reserved field. Initialized to zero for transmission; 641 ignored on reception. 643 5. Source Routing Node Operation 645 5.1. Processing of ICMP "RRH Warning" 647 The New ICMP message "RRH Warning" is presented in Section 4.2. This 648 message is addressed to the SRN which performs the tunnel 649 encapsulation and generates the RRH. 651 Hence, a SRN that receives the ICMP "RRH Warning" MUST NOT propagate 652 it to the originating SRN or inner tunnel source, but MUST process it 653 for itself. 655 If the Current Size in the ICMP messages matches the actual current 656 number of slots in RRH, and if the ICMP passes some safety checks as 657 described in Section 4.2, then the SRN MAY adapt the number of slots 658 to the Proposed Size. 660 5.2. Processing of ICMP error 662 When the SRN receives an ICMP error message, it checks whether it is 663 the final destination of the packet by looking at the included 664 packet. If the included packet has an RRH, then the SRN should 665 transform it in a RH type 4 to forward the ICMP to the original 666 source of the packet. If the included packet has an FRRH, then the 667 SRN may reverse it into a RH type 4 to forward the ICMP to the 668 original source of the packet. 670 5.3. Processing of RRH Packets 672 A router that receives a RRH is a link scoped protocol packet may 673 save that RRH and associate it with the propagation of the protocol 674 information. the router performs ULP checksum validation and security 675 header checks including the RRH as received 677 When the router sends the propagated protocol information over an 678 interface, the router adds one of its addresses from that interface 679 at the head of the RRH, and then computes upper layer checksums and 680 IPSec/AH signatures as required. 682 It is preferred that the address as a scope that is as large as the 683 Source Route Domain, in order to enable a loose operation. In 684 particular, if the router has consistent states to route to the 685 seconds most recent entry via the source address of the packet, then 686 it can overwrite the most recent entry with its own. 688 The node at the end of the propagation and any node on the way may 689 decide to keep a source route state towards the address located in 690 slot 0 using a source route path that is directly inferred from the 691 RRH. 693 5.4. Processing of FRRH Packets 695 A router that receives a FRRH is a link scoped protocol packet may 696 save that RRH and associate it with the propagation of the protocol 697 information. the router performs ULP checksum validation and security 698 header checks including the FRRH as received. 700 Then the router adds an address from the ingress interface at the end 701 of the FRRH, which is now ready to be associated to the propagation 702 of the protocol. When the router sends the propagated protocol 703 information over an interface, it adds the FRRH as and computes upper 704 layer checksums and IPSec/AH signatures as required. 706 The node at the end of the propagation and any node on the way may 707 decide to reverse the FRRH into a RRH and send it back to the source 708 located in slot 0 for the FRRH, which in turn can reverse it again, 709 this time into a RH type 4. 711 6. Security Considerations 713 The FRRH and the RRH are propagated as part of a higher hop-by-hop 714 protocol operation, so it is not mutable. Each hop adds its info, 715 then computes the checksum and IPSec headers and then it transmits 716 with a link scope to the next node(s) on the way of the upper layer 717 protocol operation. 719 This section is not complete; further work is needed to analyze and 720 solve the security problems of record and source route. 722 7. IANA considerations 724 This document requires IANA to define 2 new IPv6 Routing Header types 725 for Forward Record Routing Header and Reverse Routing Header. The 726 allocation is governed by [I-D.ietf-6man-iana-routing-header] The 727 desired values would be 3 for FRRH and 5 for RRH. 729 This document also requires the allocation of a new ICMP error type 730 "RRH Warning" with a proposed value of 64. 732 8. Protocol Constants 734 DEF_RRH_SLOTS: 7 736 MAX_RRH_SLOTS: 10 738 9. Acknowledgements 740 The author wishes to thank Mukul Goyal and Emmanuel Baccelli for 741 their contributions and reviews. Also Jonathan Hui, JP Vasseur, Dave 742 Culler and Vishwas Manral for their work on RH 4 from which this 743 works inherits. 745 10. References 747 10.1. informative reference 749 [I-D.ietf-6man-iana-routing-header] 750 Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 751 the IPv6 Routing Header", 752 draft-ietf-6man-iana-routing-header-00 (work in progress), 753 October 2009. 755 [I-D.ietf-6man-rpl-routing-header] 756 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 757 Routing Header for Source Routes with RPL", 758 draft-ietf-6man-rpl-routing-header-01 (work in progress), 759 October 2010. 761 [I-D.ietf-roll-p2p-rpl] 762 Goyal, M. and E. Baccelli, "Reactive Discovery of Point- 763 to-Point Routes in Low Power and Lossy Networks", 764 draft-ietf-roll-p2p-rpl-01 (work in progress), 765 October 2010. 767 [I-D.ietf-roll-rpl] 768 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 769 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 770 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 771 Lossy Networks", draft-ietf-roll-rpl-16 (work in 772 progress), December 2010. 774 [I-D.ietf-roll-terminology] 775 Vasseur, J., "Terminology in Low power And Lossy 776 Networks", draft-ietf-roll-terminology-04 (work in 777 progress), September 2010. 779 10.2. normative reference 781 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 782 September 1981. 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, March 1997. 787 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 788 Internet Protocol", RFC 2401, November 1998. 790 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 791 RFC 2402, November 1998. 793 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 794 Payload (ESP)", RFC 2406, November 1998. 796 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 797 (IPv6) Specification", RFC 2460, December 1998. 799 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 800 Protocol (ICMPv6) for the Internet Protocol Version 6 801 (IPv6) Specification", RFC 2463, December 1998. 803 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 804 an On-line Database", RFC 3232, January 2002. 806 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 807 in IPv6", RFC 3775, June 2004. 809 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 810 Neighbor Discovery (SEND)", RFC 3971, March 2005. 812 Author's Address 814 Pascal Thubert (editor) 815 Cisco Systems 816 ViAddge d'Entreprises Green Side 817 400, Avenue de Roumanille 818 Batiment T3 819 Biot - Sophia Antipolis 06410 820 FRANCE 822 Phone: +33 497 23 26 34 823 Email: pthubert@cisco.com