idnits 2.17.00 (12 Aug 2021) /tmp/idnits8155/draft-thubert-nemo-reverse-routing-header-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 602: '...e RH type 0, and the RH type 0 MUST be...' RFC 2119 keyword, line 646: '...es the RRH. The Proposed Size MUST be...' RFC 2119 keyword, line 647: '...current size and MUST NOT be larger th...' RFC 2119 keyword, line 656: '...stination and it MUST NOT forward it t...' RFC 2119 keyword, line 859: '... The TLMR MUST include this option i...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 11, 2002) is 7162 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '0' is mentioned on line 544, but not defined == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-03) exists of draft-kniveton-mobrtr-02 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 2401 (ref. '7') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '8') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '9') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2460 (ref. '10') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '11') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2463 (ref. '12') (Obsoleted by RFC 4443) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '13') Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thubert 3 Internet-Draft M. Molteni 4 Expires: April 11, 2003 Cisco Systems 5 October 11, 2002 7 IPv6 Reverse Routing Header and its application to Mobile Networks 8 draft-thubert-nemo-reverse-routing-header-01 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 http:// 26 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 This Internet-Draft will expire on April 11, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 Already existing proposals enable Mobile Networks by extending Mobile 40 IP to support Mobile Routers. In order to enable nested Mobile 41 Networks, some involve the overhead of nested tunnels between the 42 Mobile Routers and their Home Agents. 44 This proposal allows the building of a nested Mobile Network avoiding 45 the nested tunnel overhead. This is accomplished by using a new 46 routing header, called the reverse routing header, and by overlaying 47 a layer 3 tree topology on the evolving Mobile Network. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1 Extending existing solutions . . . . . . . . . . . . . . . . 4 53 2. Terminology and Assumptions . . . . . . . . . . . . . . . . 5 54 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. An Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. New Routing Headers . . . . . . . . . . . . . . . . . . . . 10 58 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . . 10 59 4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . . 12 60 4.3 Extension Header order . . . . . . . . . . . . . . . . . . . 14 61 5. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 17 63 6.1 Modified Router Advertisement Message Format . . . . . . . . 17 64 6.2 New Tree Information Option Format . . . . . . . . . . . . . 18 65 7. Binding Cache Management . . . . . . . . . . . . . . . . . . 20 66 7.1 Binding Updates . . . . . . . . . . . . . . . . . . . . . . 20 67 7.2 RRH Heartbeat . . . . . . . . . . . . . . . . . . . . . . . 20 68 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 21 69 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 22 70 9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . . 23 71 9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . . 23 72 9.3 Processing of RHH for Outbound Packets . . . . . . . . . . . 24 73 9.4 Processing of Tree Information Option . . . . . . . . . . . 24 74 9.5 Processing of the extended Routing Header Type 2 . . . . . . 25 75 9.6 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 26 76 10. Mobile Host Operation . . . . . . . . . . . . . . . . . . . 26 77 11. Security Considerations . . . . . . . . . . . . . . . . . . 27 78 11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . . . 27 79 11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . . . 28 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 81 References . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 83 A. Optimizations . . . . . . . . . . . . . . . . . . . . . . . 30 84 A.1 Prefix Scope Binding Updates . . . . . . . . . . . . . . . . 30 85 A.2 Path Optimization with RRH . . . . . . . . . . . . . . . . . 31 86 A.3 Packet Size Optimization . . . . . . . . . . . . . . . . . . 32 87 A.3.1 Routing Header Type 3 (HAddr option replacement) . . . . . . 34 88 B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . . 35 89 B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . . 35 90 B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . . 36 91 C. Changes from Previous Version of the Draft . . . . . . . . . 37 92 Full Copyright Statement . . . . . . . . . . . . . . . . . . 38 94 1. Introduction 96 This document assumes the reader is familiar with the Mobile Networks 97 terminology defined in [2] and with Mobile IPv6 defined in [1]. 99 Generally a Mobile Network may be either simple (a network with one 100 mobile router) or nested, single or multi-homed. This proposal 101 starts from the assumption that nested Mobile Networks will be the 102 norm, and so presents a solution that avoids the tunnel within tunnel 103 overhead of already existing proposals. 105 The solution is based on a single bi-directional tunnel between the 106 first Mobile Router (MR) to forward a packet and its Home Agent (HA). 107 By using IPsec ESP on that tunnel, home equivalent privacy is 108 obtained without further encapsulation. 110 The solution uses a new Routing Header (RH), called the Reverse 111 Routing Header (RRH), to provide an optimized path for the single 112 tunnel. RRH is a variant of IPv4 Loose Source and Record Route 113 (LSRR) [6] adapted for IPv6. RRH records the route out of the nested 114 Mobile Network and can be trivially converted into a routing header 115 for packets destined to the Mobile Network. 117 This version focuses on single-homed Mobile Networks. Hints for 118 further optimizations and multi-homing are given in the appendixes. 120 Local Fixed Node (LFN) and Correspondent Node (CN) operations are 121 left unchanged as in [1]. Specifically the CN can also be a LFN. 123 Section 3 proposes an example to illustrate the operation of the 124 proposed solution, leaving detailed specifications to the remaining 125 chapters. The reader may refer to Section 2.1 for the specific 126 terminology. 128 1.1 Extending existing solutions 130 This proposal extends [1] to support simple and nested Mobile 131 Networks. 133 This paper also builds on an other existing proposal, [3], which is 134 based on nested tunnels, in order to address the following problems, 135 introduced by that solution: 137 "Pinball" routing 139 Both inbound and outbound packets will flow via the HAs of all the 140 MRs on their path within the Mobile Network, with increased 141 latency, less resilience and more bandwidth usage. 143 Packet size 145 An extra IPv6 header is added per level of nesting to all the 146 packets. The header compression suggested in [5] cannot be 147 applied because both the source and destination (the intermediate 148 MR and its HA), are different hop to hop. 150 2. Terminology and Assumptions 152 2.1 Terminology 154 Simple Mobile Network 156 One or more IP subnets attached to a MR and mobile as a unit, with 157 respect to the rest of the Internet. A simple Mobile Network can 158 be either single or multi-homed. 160 The IP subnets may have any kind of topology and may contain fixed 161 routers. All the access points of the Mobile Network (to which 162 further MRs may attach) are on the same layer 2 link of the MR. 164 We like to represent a simple single-homed Mobile Network as an 165 hanger, because it has only one uplink hook and a bar to which 166 multiple hooks can be attached. Graphically we use the question 167 mark "?" to show the uplink hook (interface) connected to the MR, 168 and the "=" sign to represent the bar: 170 ? 171 MR1 172 | 173 =============== 175 Nested Mobile Network 177 A group of simple Mobile Networks recursively attached together 178 and implementing nested Mobility as defined in [2]. 180 ? 181 MR1 182 | 183 ====?===============?==== 184 MR2 MR3 185 | | 186 =========== ===?==========?=== 187 MR4 MR5 188 | | 189 ========== ============ 191 IPv6 Mobile Host 193 A IPv6 Host, with support for MIPv6 MN, and the additional Nemo 194 capability described in this draft. 196 Home prefix 198 Network prefix, which identifies the home link within the Internet 199 topology. 201 Mobile Network prefix 203 Network prefix, common to all IP addresses in the Mobile Network 204 when the MR is attached to the home link. It may or may not be a 205 subset of the Home subnet prefix. 207 Inbound direction: 209 direction from outside the Mobile Network to inside 211 Outbound direction: 213 direction from inside the Mobile Network to outside 215 2.2 Assumptions 217 We make the following assumptions: 219 1. A MR has one Home Agent and one Home Address -> one primary CoA. 221 2. A MR attaches to a single Attachment Router as default router. 223 3. A MR may have more than one uplink interface. 225 4. An interface can be either wired or wireless. The text assumes 226 that interfaces are wireless for generality. 228 5. Each simple Mobile Network may have more that one L2 Access 229 Point, all of them controlled by the same Attachment Router, 230 which we assume to be the Mobile Router. 232 Since an MR has only one primary CoA, only one uplink interface can 233 be used at a given point of time. Since the MR attaches to a single 234 attachment router, if due care is applied to avoid loops, then the 235 resulting topology is a tree. 237 3. An Example 239 The nested Mobile Network in the following figure has a tree 240 topology, according to the assumptions in Section 2.2. In the tree 241 each node is a simple Mobile Network, represented by its MR. 243 +---------------------+ 244 | Internet |---CN 245 +---------------|-----+ 246 / Access Router 247 MR3_HA | 248 ======?====== 249 MR1 250 | 251 ====?=============?==============?=== 252 MR5 MR2 MR6 253 | | | 254 =========== ===?========= ============= 255 MR3 256 | 257 ==|=========?== <-- Mobile Network3 258 LFN1 MR4 259 | 260 ========= 262 An example nested Mobile Network 264 This example focuses on a Mobile Network node at depth 3 (Mobile 265 Network3) inside the tree, represented by its mobile router MR3. The 266 path to the Top Level Mobile Router (TLMR) MR1 and then the Internet 267 is 269 MR3 -> MR2 -> MR1 -> Internet 271 Consider the case where a LFN belonging to Mobile Network3 sends a 272 packet to a CN in the Internet, and the CN replies back. With the 273 tunnel within tunnel approach described by [3], we would have three 274 bi-directional nested tunnels: 276 -----------. 277 --------/ /-----------. 278 -------/ | | /----------- 279 CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN 280 MR3_HA -------\ | | \----------- MR3 281 MR2_HA --------\ \----------- MR2 282 MR1_HA ----------- MR1 284 Depending on the relative location of MR1_HA, MR2_HA and MR3_HA, this 285 may lead to a very inefficient "pinball" routing in the 286 Infrastructure. 288 On the other hand, with the RRH approach we would have only one bi- 289 directional tunnel: 291 --------------------------------- MR1 ---- MR2 ---- MR3 292 CN ------( - - - - - - - - - - - - - - - - (-------- LFN 293 MR3_HA --------------------------------- MR1 ---- MR2 ---- MR3 295 The first mobile router on the path, MR3, in addition to tunneling 296 the packet to its HA, adds a reverse routing header with N = 3 pre- 297 allocated slots. Choosing the right value for N is discussed in 298 Section 6.2. The bottom slot is equivalent to the MIPv6 Home Address 299 option. MR3 inserts its home address MR3_HAddr into slot 0. 301 The outer packet has source MR3's CareOf Address (CoA), MR3_CoA and 302 destination MR3's Home Agent, MR3_HA: 304 <-------------- outer IPv6 header --------------------> 305 +-------+-------++ -- ++----+-------+-------+---------+ +------- 306 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 307 |MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HAddr| |iPACKET 308 | | |: :| 4 | | | | | 309 +-------+-------++ -- ++----+-------+-------+---------+ +------- 311 The second router on the path, MR2, notices that the packet already 312 contains an RRH, and so it overwrites the source address of the 313 packet with its own address, MR2_CoA, putting the old source address, 314 MR3_CoA, in the first free slot of the RRH. 316 The outer packet now has source MR2_CoA and destination MR3_HA; the 317 RRH from top to bottom is MR3_CoA | MR3_HAddr: 319 <-------------- outer IPv6 header --------------------> 320 +-------+-------++ -- ++----+-------+-------+---------+ +------- 321 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 322 |MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA|MR3_HAddr| |iPACKET 323 | | |: :| 4 | | | | | 324 +-------+-------++ -- ++----+-------+-------+---------+ +------- 325 In general the process followed by the second router is repeated by 326 all the routers on the path, including the TLMR (in this example 327 MR1). When the packet leaves MR1 the source address is MR1_CoA and 328 the RRH is MR2_CoA | MR3_CoA | MR3_HAddr: 330 <-------------- outer IPv6 header --------------------> 331 +-------+-------++ -- ++----+-------+-------+---------+ +------- 332 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 333 |MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HAddr| |iPACKET 334 | | |: :| 4 | | | | | 335 +-------+-------++ -- ++----+-------+-------+---------+ +------- 337 In a colloquial way we may say that while the packet travels from MR3 338 to MR3_HA, the Mobile Network tunnel end point "telescopes" from MR3 339 to MR2 to MR1. 341 When the home agent MR3_HA receives the packet it notices that it 342 contains a RRH and it looks at the bottom entry, MR3_HAddr. This 343 entry is used as if it were a MIPv6 Home Address destination option, 344 i.e. as an index into the Binding Cache. When decapsulating the 345 inner packet the home agent performs the checks described in Section 346 8, and if successful it forwards the inner packet to CN. 348 MR3_HA stores two items in the Bind Cache Entry associated with MR3: 349 the address entries from RRH, to be used to build the RH, and the 350 packet source address MR1_CoA, to be used as the first hop. 352 Further packets from the CN to the LFN are plain fixed IPv6 packets. 353 Destination is LFN, and so the packet reaches MR3's home network. 355 MR3_HA intercepts it, does a Bind Cache prefix lookup and obtains as 356 match the MR3 entry, containing the first hop and the information 357 required to build the RH. It then puts the packet in the tunnel 358 MR3_HA -- MR3 as follows: source address MR3_HA and destination 359 address the first hop, MR1_CoA. The RH is trivially built out of the 360 previous RRH: MR2_CoA | MR3_CoA | MR3_HAddr: 362 <-------------- outer IPv6 header --------------------> 363 +-------+-------++ -- ++----+-------+-------+---------+ +------- 364 |oSRC |oDST |: :|oRH | | | | | 365 |MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HAddr| |iPACKET 366 | | |: :| 2 | | | | | 367 +-------+-------++ -- ++----+-------+-------+---------+ +------- 368 The packet is routed with plain IP routing up to the first 369 destination MR1_CoA. 371 The RH of the outer packet is type 2 as in [1], but has additional 372 semantics inherited from type 0: it contains the path information to 373 traverse the nested Mobile Network from the TLMR to the tunnel 374 endpoint MR. Each intermediate destination forwards the packet to 375 the following destination in the routing header. The security 376 aspects of this are treated in Section 11.2. 378 MR1, which is the initial destination in the IP header, looks at the 379 RH and processes it according to Section 9, updating the RH and the 380 destination and sending it to MR2_CoA. MR2 does the same and so on 381 until the packet reaches the tunnel endpoint, MR3. 383 When the packet reaches MR3, the source address in the IP header is 384 MR3_HA, the destination is MR3_CoA and in the RH there is one segment 385 left, MR3_HAddr. As a consequence the packet belongs to the MR3_HA - 386 - MR3 tunnel. MR3 decapsulates the inner packet, applying the rules 387 described in Section 9 and sends it to LFN. The packet that reaches 388 LFN is the plain IPv6 packet that was sent by CN. 390 4. New Routing Headers 392 This draft modifies the MIPv6 Routing Header type 2 and introduces 393 two new Routing Headers, type 3 and 4. Type 3 will be discussed in 394 Appendix A.3.1. The draft presents their operation in the context of 395 Mobile Routers although the formats are not tied to MIP and could be 396 used in other situations. 398 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) 400 Mobile IPv6 uses a Routing header to carry the Home Address for 401 packets sent from a Correspondent Node to a Mobile Node. In [1], 402 this Routing header (Type 2) is restricted to carry only one IPv6 403 address. The format proposed here extends the Routing Header type 2 404 to be multi-hop. 406 The processing of the multi-hop RH type 2 inherits from the RH type 0 407 described in [10]. Specifically: the restriction on multicast 408 addresses is the same; a RH type 2 is not examined or processed until 409 it reaches the node identified in the Destination Address field of 410 the IPv6 header; in that node, the RH type 0 algorithm applies, with 411 added security checks. 413 The construction of the multi-hop RH type 2 by the HA is described in 414 Section 8; the processing by the MRs is described in Section 9.5; and 415 the security aspects are treated in Section 11.2. 417 The multi-hop Routing Header type 2, as extended by this draft, has 418 the following format: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Next Header | Hdr Ext Len | Routing Type=2| Segments Left | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Reserved | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 + + 429 | | 430 + Address[1] + 431 | | 432 + + 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | | 436 + + 437 | | 438 + Address[2] + 439 | | 440 + + 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 . . . 444 . . . 445 . . . 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 + + 449 | | 450 + Address[n] + 451 | | 452 + + 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Next Header 458 8-bit selector. Identifies the type of header immediately 459 following the Routing header. Uses the same values as the IPv4 460 Protocol field [13]. 462 Hdr Ext Len 464 8-bit unsigned integer. Length of the Routing header in 8-octet 465 units, not including the first 8 octets. For the Type 2 Routing 466 header, Hdr Ext Len is equal to two times the number of addresses 467 in the header. 469 Routing Type 471 8-bit unsigned integer. Set to 2. 473 Segments Left 475 8-bit unsigned integer. Number of route segments remaining, i.e., 476 number of explicitly listed intermediate nodes still to be visited 477 before reaching the final destination. 479 Reserved 481 32-bit reserved field. Initialized to zero for transmission; 482 ignored on reception. 484 Address[1..n] 486 Vector of 128-bit addresses, numbered 1 to n. 488 The destination node of a packet containing a RH type 2 can be a MR 489 or some other kind of node. If it is a MR it will perform the 490 algorithm described in Section 9.5, otherwise it will operate as 491 prescribed by IPv6 [10] when the routing type is unrecognized. 493 4.2 Routing Header Type 4 (The Reverse Routing Header) 495 The Routing Header type 4, or Reverse Routing Header (RRH), is a 496 variant of IPv4 loose source and record route (LSRR) [6] adapted for 497 IPv6. 499 Addresses are added from bottom to top (0 to n-1 in the picture). 500 The RRH is designed to help the destination build an RH for the 501 return path. 503 When a RRH is present in a packet, the rule for upper-layer checksum 504 computing is that the source address used in the pseudo-header is 505 that of the original source, located in the slot 0 of the RRH, unless 506 the RRH slot 0 is empty, in which case the source in the IP header of 507 the packet is used. 509 As the 'segment left' field of the generic RH is reassigned to the 510 number of segments used, a IPv6 Host that does not support RRH will 511 discard the packet, unless the RRH is empty. 513 The Type 4 Routing Header has the following format: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Next Header | Hdr Ext Len | Routing Type=4| Segments Used | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Sequence Number | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | 523 + + 524 | | 525 + Slot[n-1] + 526 | | 527 + + 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 . . . 531 . . . 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 + + 535 | | 536 + Slot[1] (1st MR CoA) + 537 | | 538 + + 539 | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | 542 + + 543 | | 544 + Slot[0] (Home address) + 545 | | 546 + + 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Next Header 552 8-bit selector. Identifies the type of header immediately 553 following the Routing header. Uses the same values as the IPv4 554 Protocol field [13]. 556 Hdr Ext Len 558 8-bit unsigned integer. Length of the Routing header in 8-octet 559 units, not including the first 8 octets. For the Type 4 Routing 560 header, Hdr Ext Len is equal to two times the number of addresses 561 in the header. 563 Routing Type 565 8-bit unsigned integer. Set to 4. 567 Segments Used 569 8-bit unsigned integer. Number of slots used. Initially set to 1 570 by the MR when only the Home Address is there. Incremented by the 571 MRs on the way as they add the packets source addresses to the 572 RRH. 574 Sequence Number 576 32-bit unsigned integer. The Sequence Number starts at 0, and is 577 incremented by the source upon each individual packet. Using the 578 Radia Perlman's lollipop algorithm, values between 0 and 255 are 579 'negative', left to indicate a reboot or the loss of HA 580 connectivity, and are skipped when wrapping and upon positive 581 Binding Ack. The sequence number is used to check the freshness 582 of the RRH; anti-replay protection is left to IPsec AH. 584 Slot[n-1..0] 586 Vector of 128-bit addresses, numbered n-1 to 0. 588 When applied to the Nemo problem, the RRH can be used to update the 589 HA on the actual location of the MR. Only MRs forwarding packets on 590 an egress interface while not at home update it on the fly. 592 A RRH is inserted by the first MR on the Mobile Network outbound 593 path, as part of the reverse tunnel encapsulation; it is removed by 594 the associated HA when the tunneled packet is decapsulated. The RRH 595 contains n pre-allocated address slots, to be filled by each MR in 596 the path. 598 4.3 Extension Header order 600 The RH type 2 is to be placed as any RH as described in [10] section 601 4.1. If a RH type 0 is present in the packet, then the RH type 2 is 602 placed immediately after the RH type 0, and the RH type 0 MUST be 603 consumed before the RH type 2. 605 RH type 3 and 4 are mutually exclusive. They are to be placed right 606 after the Hop-by-Hop Options header if any, or else right after the 607 IPv6 header. 609 As a result, the order prescribed in section 4.1 of RFC 2460 becomes: 611 IPv6 header 613 Hop-by-Hop Options header 615 Routing header type 3 or 4 617 Destination Options header (note 1) 619 Routing header type 0 621 Routing header type 2 623 Fragment header 625 Authentication header (note 2) 627 Encapsulating Security Payload header (note 2) 629 Destination Options header (note 3) 631 upper-layer header 633 5. ICMP 635 The RRH could have fewer slots than the number of MRs in the path 636 because either the nested Mobile Network topology is changing too 637 quickly or the MR that inserted the RRH could have a wrong 638 representation of the topology. 640 To solve this problem a new ICMP message is introduced, "RRH 641 Warning", type 64. Note that this ICMP message creates a new class 642 of warning messages besides the error messages and the control 643 messages of ICMP. 645 This message allows a MR on the path to propose a larger number of 646 slots to the MR that creates the RRH. The Proposed Size MUST be 647 larger than the current size and MUST NOT be larger than 8. 649 The originating MR must rate-limit the ICMP messages to avoid 650 excessive ICMP traffic in the case of the source failing to operate 651 as requested. 653 The originating MR must insert an RH type 2 based on the RRH in the 654 associated IP header, in order to route the ICMP message back to the 655 source of the reverse tunnel. A MR that receives this ICMP message 656 is the actual destination and it MUST NOT forward it to the (LFN) 657 source of the tunneled packet. 659 The type 64 ICMP has the following format: 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Type = 64 | Code = 0 | Checksum | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Current Size | Proposed Size | Reserved | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | As much of invoking packet | 669 + as will fit without the ICMPv6 packet + 670 | exceeding the minimum IPv6 MTU | 671 . . 672 . . 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 Type 677 64 [To Be Assigned] 679 Code 0: RRH too small 681 The originating MR requires the source to set the RRH size to a 682 larger value. The packet that triggered the ICMP will still be 683 forwarded by the MR, but the path cannot be totally optimized (see 684 Section 9.3). 686 Checksum 688 The ICMP checksum [12]. 690 Current Size 692 RRH size of the invoking packet, as a reference. 694 Proposed Size 696 The new value, expressed as a number of IPv6 addresses that can 697 fit in the RRH. 699 Reserved 701 16-bit reserved field. Initialized to zero for transmission; 702 ignored on reception. 704 6. Modifications to IPv6 Neighbor Discovery 706 6.1 Modified Router Advertisement Message Format 708 Mobile IPv6 [1] modifies the format of the Router Advertisement 709 message [11] by the addition of a single flag bit (H) to indicate 710 that the router sending the Advertisement message is serving as a 711 home agent on this link. 713 This draft adds another single flag bit (N) to indicate that the 714 router sending the advertisement message is a MR. This means that 715 the link on which the message is sent is a Mobile Network, which may 716 or may not be at home. 718 The Router Advertisement message has the following format: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Type | Code | Checksum | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Reachable Time | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Retrans Timer | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Options ... 732 +-+-+-+-+-+-+-+-+-+-+-+- 734 This format represents the following changes over that originally 735 specified for Neighbor Discovery [11]: 737 Home Agent (H) 739 The Home Agent (H) bit is set in a Router Advertisement to 740 indicate that the router sending this Router Advertisement is also 741 functioning as a Mobile IP home agent on this link. 743 NEMO Capable (N) 745 The NEMO Capable (N) bit is set in a Router Advertisement to 746 indicate that the router sending this Router Advertisement is also 747 functioning as a Mobile Router on this link, so that the link is a 748 Mobile Network, possibly away from home. 750 6.2 New Tree Information Option Format 752 This draft defines a new Tree Information Option, used in Router 753 Advertisement messages. Fields set by the TLMR are propagated 754 transparently by the MRs. 756 The Tree Information option has the following format: 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type | Length = 5 | Tree_Prefer. | TreeDepth | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |F|H| Reserved | Bandwidth | DelayTime | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | MRPreference | BootTimeRandom | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | PathCRC | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | | 770 + + 771 | | 772 + Tree TLMR Identifier + 773 | | 774 + + 775 | | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | | 778 + + 779 | | 780 + Tree Group + 781 | | 782 + + 783 | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Type 788 8-bit unsigned integer set to 7 by the TLMR. 790 Length 792 8-bit unsigned integer set to 6 by the TLMR. The length of the 793 option (including the type and length fields) in units of 8 794 octets. 796 Tree_Preference 797 8-bit unsigned integer set by the TLMR to its configured 798 preference. Range from 0 = lowest to 255 = maximum. 800 TreeDepth 802 8-bit unsigned integer set to 0 by the TLMR and incremented by 1 803 by each MR down the tree. 805 Fixed (F) 807 1-bit flag. Set by the TLMR to indicate that it is either 808 attached to a fixed network or at home. 810 Home (H) 812 1-bit flag. Set by the TLMR to indicate that it is also 813 functioning as a HA, for re-homing purposes. 815 Reserved 817 6-bit unsigned integer, set to 0 by the TLMR. 819 Bandwidth 821 8-bit unsigned integer set by the TLMR and decremented by MRs with 822 lower egress bandwidth. This is a power of 2 so that the 823 available egress bandwidth in bps is between 2^Bandwidth and 824 2^(Bandwidth+1). 0 means 'unspecified' and can not be modified 825 down the tree. 827 DelayTime 829 16-bit unsigned integer set by the TLMR. Tree time constant in 830 milliseconds. 832 MRPreference 834 8-bit signed integer. Set by each MR to its configured 835 preference. Range from 0 = lowest to 255 = maximum. 837 BootTimeRandom 839 24-bit unsigned integer set by each MR to a random value that the 840 MR generates at boot time. 842 PathCRC 844 Updated by each MR. This is the result of a CRC-32 computation on 845 a bit string obtained by appending the received value and the MR 846 CareOf Address. TLMRs use a 'previous value' of zeroes to 847 initially set the pathCRC. 849 Tree TLMR Identifier 851 IPv6 global address, set by the TLMR. Identifier of the tree. 853 Tree Group 855 IPv6 global address, set by the TLMR. Identifier of the tree 856 group. A MR may use the Tree Group in its tree selection 857 algorithm. 859 The TLMR MUST include this option in its Router Advertisements. 861 A MR receiving this option from its Attachment Router MUST update the 862 TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST 863 propagate it on its ingress interface(s), as described in Section 864 9.4. 866 The alignment requirement of the Tree Information Option is 8n. 868 7. Binding Cache Management 870 7.1 Binding Updates 872 Binding Updates are still used as described in MIPv6 [1] for Home 873 Registration and de-registration, but only when the MR registers for 874 the first time with its HA. 876 Since the BU doesn't contain the full NEMO path to the MR, it cannot 877 be used in this design of nested Mobile Networks. 879 7.2 RRH Heartbeat 881 Subsequent updates (or just refreshes) to the CoA binding are 882 obtained as one of the results of processing the RRH by the HA. 884 When the MR becomes aware of a topology change in the tree (for 885 examples it changes point of attachment, it obtains a new CoA, it 886 receives a Tree Information message) or in the absence of traffic 887 (detected by a timeout) to the HA, it must send an RRH Heartbeat (IP 888 packet with the RRH and empty payload). 890 Security issues are discussed in Section 11.2. 892 8. Home Agent Operation 894 This section inherits from chapter 10 [1], which is kept unmodified 895 except for parts 10.5 and 10.6 which are extended. This draft mostly 896 adds the opportunity for an MN to update the Binding Cache of its 897 Home Agent using RRH, though it does not change the fact that MNs 898 still need to select a home agent, register and deregister to it, 899 using the MIP Bind Update. 901 This draft extends [1] section 10.6 as follows: 903 o The entry point of the tunnel is now checked against the TLMR as 904 opposed to the primary CoA. 906 o The Binding Cache can be updated based on RRH with proper AH 907 authentication. 909 As further explained in Section 7.1, this specification modifies MIP 910 so that HA can rely on the RH type 4 (RRH) to update its the Bind 911 Cache Entry (BCE), when the Mobile Node moves. The conceptual 912 content of the BCE is extended to contain a sequence counter, and the 913 sequence of hops within the -potentially nested- Mobile Network to a 914 given Mobile Node. The sequence counter is initially set to 0. 916 When the HA gets a packet destined to itself, it checks for the 917 presence of a Routing Header of type 3 or 4. Both contain as least 918 the entry for the home address of the MN in slot 0; this replaces the 919 MIP Home Address Option and allows the HA to determine the actual 920 source of the packet, to access the corresponding security 921 association. 923 As explained in Section 11.2, the HA MUST verify the authenticity of 924 the packet using IPSEC AH and drop packets that were not issued by 925 the proper Mobile Node. An RRH is considered only if the packet is 926 authenticated and if its sequence number is higher than the one saved 927 in the BCE. 929 Also, an RRH is considered only if an initial Bind Update exchange 930 has been successfully completed between the Mobile Node and its Home 931 Agent for Home Registration. If the RRH is valid, then the Bind 932 Cache Entry is revalidated for a lifetime as configured from the 933 initial Bind Update. 935 The BCE abstract data is updated as follows: 937 The first hop for the return path is the last hop on the path of 938 the incoming packet, that is between the HA and the Top Level 939 Mobile Router (TLMR) of the Mobile Network. The HA saves the IP 940 address of the TLMR from the source field in the IP header. 942 The rest of the path to the MN is found in the RRH. 944 The sequence counter semantics is changed as described in Section 945 4.2 947 This draft extends [1] section 10.5 as follows: 949 A Home Agent advertises the prefixes of its registered Mobile 950 Routers, during the registration period, on the local Interior 951 Gateway Protocol (IGP). 953 The Routing Header type 2 is extended to be multi-hop. 955 The Home Agent is extended to support routes to prefixes that are 956 owned by Mobile Routers. This can be configured statically, or can 957 be exchanged using a routing protocol as in [3], which is out of the 958 scope of this document. As a consequence of this process, the Home 959 Agent which is selected by a Mobile Router advertises reachability of 960 the MR prefixes for the duration of the registration over the local 961 IGP. 963 When a HA gets a packet for which the destination is a node behind a 964 Mobile Router, it places the packet in the tunnel to the associated 965 MR. This ends up with a packet which destination address in the IP 966 Header is the TLMR, and with a Routing Header of type 2 for the rest 967 of the way to the Mobile Router, which may be multi-hop. 969 To build the RH type 2 from the RRH, the HA sets the type to 2, and 970 clears the bits 32-63 (byte 4 to 7). 972 9. Mobile Router Operation 974 This section inherits from chapter 11 of [1], which is extended to 975 support Mobile Networks and Mobile Routers as a specific case of 976 Mobile Node. 978 This draft extends section 11.2.1 of [1] as follows: 980 o When not at home, an MR uses a reverse tunnel with its HA for all 981 the traffic that is sourced in its mobile network(s); traffic 982 originated further down a nested network is not tunneled twice but 983 for exception cases. 985 o The full path to and within the Mobile Network is piggy-backed 986 with the traffic on a per-packet basis to cope with rapid 987 movement. This makes the packet construction different from 988 MIPv6. 990 The MR when not at home sets up a bi-directional tunnel with its HA. 991 The reverse direction MR -> HA is needed to assure transparent 992 topological correctness to LFNs, as in [3]. But, as opposed to that 993 solution, nested tunnels are generally avoided. 995 9.1 Processing of ICMP "RRH too small" 997 The New ICMP message "RRH too Small" is presented in Section 5. This 998 message is addressed to the MR which performs the tunnel 999 encapsulation and generates the RRH. 1001 Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate 1002 it to the originating LFN or inner tunnel source, but MUST process it 1003 for itself. 1005 If the Current Size in the ICMP messages matches the actual current 1006 number of slots in RRH, and if the ICMP passes some safety checks as 1007 described in Section 5, then the MR MAY adapt the number of slots to 1008 the Proposed Size. 1010 9.2 Processing of ICMP error 1012 ICMP back { 1014 if RRH is present { 1015 compute RH type 2 based on RRH 1016 get packet source from IP header 1017 send ICMP error to source including RH type 2. 1018 } 1019 else { 1020 get packet source from IP header 1021 send ICMP error to source with no RH. 1022 } 1023 } 1025 When the MR receives an ICMP error message, it checks whether it is 1026 the final destination of the packet by looking at the included 1027 packet. If the included packet has an RRH, then the MR will use the 1028 RRH to forward the ICMP to the original source of the packet. 1030 9.3 Processing of RHH for Outbound Packets 1032 if no RRH in outer header /* First Mobile Router specific */ 1033 or RRH present but saturated { /* Need a nested encapsulation */ 1035 if RRH is saturated { 1036 do ICMP back (RRH too small) 1037 } 1039 /* put packet in sliding reverse tunnel */ 1040 insert new IP header plus RRH 1041 set source address to the MR Home Address 1042 set destination address to the MR Home Agent Address 1043 add an RRH with all slots zeroed out 1044 compute IPsec AH on the resulting packet 1045 } 1047 /* All MRs including first */ 1048 if packet size <= MTU { 1049 select first free slot in RRH bottom up 1050 set it to source address from IP header 1051 overwrite source address in IP header with MR CareOf 1052 transmit packet 1053 } else { 1054 do ICMP back (Packet too Big) 1055 } 1057 If the packet already contains an RRH in the outer header, and has a 1058 spare slot, the MR adds the source address from the packet IP header 1059 to the RRH and overwrites the source address in the IP header with 1060 its CoA. As a result, the packets are always topologically correct. 1062 Else, if the RRH is present but is saturated, and therefore the 1063 source IP can not be added, the MR sends a ICMP 'RRH too small' to 1064 the tunnel endpoint which originated the outer packet, using the RRH 1065 info to route it back. The ICMP message is a warning, and the packet 1066 is not discarded. Rather, the MR does a nested encapsulation of the 1067 packet in its own reverse tunnel home with an additional RRH. 1069 Else, if the packet does not have an RRH, the MR puts it in its 1070 reverse tunnel, sourced at the CoA, with an RRH indicating in slot 0 1071 the Home Address of the MR, and with proper IPsec AH as described 1072 further in Section 11.1. 1074 9.4 Processing of Tree Information Option 1076 The Tree Information Option in Router Advertisement messages allows 1077 the Mobile Router to select a tree and learn about its capabilities. 1079 The treeDepth can be used to compute the optimum number of slots in 1080 the RRH. 1082 The Option contains an entry for the home address in slot 0, and one 1083 for every CareOf on the way but that of the last Mobile Router 1084 (TLMR). As the TLMR sets the treeDepth to 0 and each MR increments 1085 it on the way down the tree, the optimum number of slots is normally 1086 (treeDepth+1), where treeDepth is the depth advertised by the MR over 1087 its Mobile Networks. 1089 9.5 Processing of the extended Routing Header Type 2 1091 if Segments Left = 0 { 1093 /* new check: packet must be looped back internally */ 1094 if packet doesn't come from a loopback interface { 1095 discard the packet 1096 return 1097 } 1099 proceed to process the next header in the packet, whose type is 1100 identified by the Next Header field in the Routing header 1101 } 1102 else if Hdr Ext Len is odd { 1103 send an ICMP Parameter Problem, Code 0, message to the Source 1104 Address, pointing to the Hdr Ext Len field, and discard the 1105 packet 1106 } 1107 else { 1108 compute n, the number of addresses in the Routing header, by 1109 dividing Hdr Ext Len by 2 1111 if Segments Left is greater than n { 1112 send an ICMP Parameter Problem, Code 0, message to the Source 1113 Address, pointing to the Segments Left field, and discard the 1114 packet 1115 } 1116 else { 1117 decrement Segments Left by 1; 1119 compute i, the index of the next address to be visited in 1120 the address vector, by subtracting Segments Left from n 1122 if Address [i] or the IPv6 Destination Address is multicast { 1123 discard the packet 1124 } 1125 else { 1126 /* new security check */ 1127 if Address [i] doesn't belong to one of the Mobile Network prefixes { 1128 discard the packet 1129 return 1130 } 1132 /* new check: keep MIPv6 behavior: prevent packets from being 1133 * forwarded outside the node. 1134 */ 1135 if Segments Left equals 0 and Address[i] isn't the node's own 1136 home address { 1137 discard the packet 1138 return 1139 } 1140 swap the IPv6 Destination Address and Address[i] 1142 if the IPv6 Hop Limit is less than or equal to 1 { 1143 send an ICMP Time Exceeded -- Hop Limit Exceeded in 1144 Transit message to the Source Address and discard the 1145 packet 1146 } 1147 else { 1148 decrement the Hop Limit by 1 1150 resubmit the packet to the IPv6 module for transmission 1151 to the new destination; 1152 } 1153 } 1154 } 1155 } 1157 9.6 Decapsulation 1159 A MR when decapsulating a packet from its HA must perform the 1160 following checks 1162 1. Destination address 1164 The destination address of the inner packet must belong to one of 1165 the Mobile Network prefixes. 1167 10. Mobile Host Operation 1169 When it is at Home, a Mobile Host issues packets with source set to 1170 its home address and with destination set to its CN, in a plain IPv6 1171 format. 1173 When a MH is not at home but is attached to a foreign link in the 1174 Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to 1175 manage its mobility. 1177 When a MH is visiting a foreign Mobile Network, it forwards its 1178 outbound packets over the reverse tunnel (including RRH) to its HA. 1179 One can view that operation as a first MR process applied on a plain 1180 IPv6 packet issued by an LFN. 1182 As a result, the encapsulating header include: 1184 with source set to the MH COA and destination set to the MH HA 1186 with slot 0 set to the MH Home Address 1188 The inner packet is the plain IPv6 packet from the MH Home Address to 1189 the CN. 1191 11. Security Considerations 1193 This section is not complete; further work is needed to analyse and 1194 solve the security problems of record and source route. 1196 Compared to MIPv6, the main security problem seems to be the fact 1197 that the RRH can be modified in transit by an in-axis attacker. It 1198 has to be noted that an in-axis attacker (for example any MR in the 1199 Mobile Network) can perform more effective attacks than modifying the 1200 RRH. 1202 Selecting the tree to attach to is a security critical operation 1203 outside of the scope of this draft. 1205 11.1 IPsec Processing 1207 The IPsec [7] AH [8] and ESP [9] can be used in tunnel mode to 1208 provide different security services to the tunnel between a MR and 1209 its HA. ESP tunnel mode SHOULD be used to provide confidentiality 1210 and authentication to the inner packet. AH tunnel mode MUST be used 1211 to provide authentication of the outer IP header fields, especially 1212 the RH. 1214 The Routing Header Type 2 is treated as Type 0, namely as mutable but 1215 predictable [8], and so will be included in the Authentication Data 1216 calculation. As per IPsec, the sender must order the field so that 1217 it appears as it will at the receiver, prior to performing the 1218 Integrity Check Value (ICV) computation. 1220 The Routing Header Type 4 is "partially mutable", and as such can be 1221 included in the Authentication Data calculation. Given the way Type 1222 4 is processed, the sender cannot order the field so that it appears 1223 as it will at the receiver; this means the receiver will have to 1224 shuffle the fields. 1226 The sender (the MR) will zero out all the slots and the Segment Used 1227 field of the RRH, and will put as source address of the outer packet 1228 its Home Address, and then will perform the ICV computation. 1230 The receiver (the HA) will put the entry in slot 0 (the MR Home 1231 Address) in the source address and will zero out all the slots and 1232 the Segment Used field of the RRH, and then will perform the ICV 1233 verification. 1235 11.2 New Threats 1237 The RH type 4 is used to construct a MIPv6 RH type 2 with additional 1238 semantics, as described in Section 4.1. Since RH type 2 becomes a 1239 multi hop option like RH type 0, care must be applied to avoid the 1240 spoofing attack that can be performed with the IPv4 source route 1241 option. This is why IPv6 [10] takes special care in responding to 1242 packets carrying Routing Headers. 1244 AH authenticates the MR Home Address identity and the RRH sequence 1245 number. The RRH sequence number is to be used to check the freshness 1246 of the RRH; anti-replay protection can be obtained if the receiver 1247 enables the anti-replay service of AH [8]. 1249 As a consequence, the only kind of successful attack seems to require 1250 to be able to modify the packet in flight. 1252 If one of the RRH entry is faked either to an address outside the 1253 tree or to an address that doesn't match the tree topology (not 1254 belonging to one of the Mobile Network prefixes at that level) then 1255 the reply packet containing a RH type 2 built out of the previous RRH 1256 will be dropped by the first MR that processes that entry, as 1257 described in Section 9. 1259 It is still an issue how to validate that the source of the outer 1260 packet is the actual TLMR as opposed to a forged IP address put by an 1261 on-axis attacker outside the Mobile Network. 1263 12. Acknowledgements 1265 The authors wish to thank David Auerbach, Fred Baker, Dana Blair, 1266 Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur, 1267 Kent Leung, Massimo Lucchina, Dan Shell and Patrick Wetterwald -last 1268 but not least :)-. 1270 References 1272 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 1273 IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July 1274 2002. 1276 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1277 draft-ernst-monet-terminology-01 (work in progress), July 2002. 1279 [3] Kniveton, T., "Mobile Router Support with Mobile IP", draft- 1280 kniveton-mobrtr-02 (work in progress), July 2002. 1282 [4] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A. 1283 Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix 1284 Scope Binding Updates)", draft-ernst-mobileip-v6-network-03 1285 (work in progress), March 2002. 1287 [5] Deering, S. and B. Zill, "Redundant Address Deletion when 1288 Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr- 1289 deletion-00 (work in progress), November 2001. 1291 [6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1292 1981. 1294 [7] Kent, S. and R. Atkinson, "Security Architecture for the 1295 Internet Protocol", RFC 2401, November 1998. 1297 [8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1298 November 1998. 1300 [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1301 (ESP)", RFC 2406, November 1998. 1303 [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1304 Specification", RFC 2460, December 1998. 1306 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1307 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1309 [12] Conta, A. and S. Deering, "Internet Control Message Protocol 1310 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1311 Specification", RFC 2463, December 1998. 1313 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 1314 line Database", RFC 3232, January 2002. 1316 Authors' Addresses 1318 Pascal Thubert 1319 Cisco Systems Technology Center 1320 Village d'Entreprises Green Side 1321 400, Avenue Roumanille 1322 Biot - Sophia Antipolis 06410 1323 FRANCE 1325 EMail: pthubert@cisco.com 1327 Marco Molteni 1328 Cisco Systems Technology Center 1329 Village d'Entreprises Green Side 1330 400, Avenue Roumanille 1331 Biot - Sophia Antipolis 06410 1332 FRANCE 1334 EMail: mmolteni@cisco.com 1336 Appendix A. Optimizations 1338 A.1 Prefix Scope Binding Updates 1340 [4] suggests modifications to MIPv6 to enable support for LFNs in 1341 non-nested Mobile Networks, leaving for later investigation more 1342 complex scenarios like MNs behind the MR or nested Mobile Networks. 1344 The solution described there has bi-directional route optimization as 1345 in MIPv6: the CN to MR direction uses the RH type 2, while the MR to 1346 CN direction uses the home address destination option. Route 1347 optimization is obtained by introducing a new kind of binding update, 1348 the Prefix Scope BU (PSBU) and by modifying the CN and MR operations 1349 in order to exploit it. 1351 The MR has to keep track of all the pending communications between 1352 hosts in his Mobile Network and their CNs, in order to send to the 1353 CNs a PSBU each time the MR changes its point of attachment. 1355 If we extend [4] in such a way that each MR in a nested Mobile 1356 Network sends a full set of PSBUs each time it changes its point of 1357 attachment, then each CN by receiving all the PSBUs and processing 1358 them can infer a partial topology of the nested Mobile Network, 1359 sufficient to build a multi-hop routing header for packets sent to 1360 nodes inside the nested Mobile Network. 1362 However, this extension seems to come at a too high price: 1364 1. PSBU storm 1366 when one MR changes its point of attachment, it needs to send a 1367 PSBU to all the CNs of each node behind him. When the Mobile 1368 Network is nested, the number of nodes and relative CNs can be 1369 huge. In order to send the PSBUs, the MR has to keep track of 1370 all the traffic it forwards to maintain his list of CNs. 1372 2. CN operation 1374 The computation burden of the CN becomes heavy, because it has to 1375 analyze each PSBU in a recursive fashion in order to deduct 1376 nested Mobile Network topology required to build a multi hop 1377 routing header. 1379 3. Missing PSBU 1381 If a CN doesn't receive the full set of PSBU sent by the MR, it 1382 will not be able to infer the full path to a node inside the 1383 nested Mobile Network. The RH will be incomplete and the packet 1384 may or may not be delivered. If PSBU are sent asynchronously by 1385 each MR, then, when the relative position of MRs and/or the TLMR 1386 point of attachment change rapidly, the image of Mobile Network 1387 that the CN maintains is highly unstable. 1389 A conclusion is that the path information must be somehow aggregated 1390 to provide the CN with consistent snapshots of the full path across 1391 the Mobile Network. If this is achieved by a series of stacked Home 1392 Address Options, then the problem turns into a format war and about 1393 the opportunity to insert headers in a packet as opposed to 1394 tunneling. Either way is a route record, which is why defining a 1395 real V6 version of LSRR is relevant in the first place. 1397 A.2 Path Optimization with RRH 1399 The body of the draft presents RRH as a header that circulates in the 1400 reverse tunnel exclusively. The RRH format by itself has no such 1401 limitation. This section illustrates a potential optimization for 1402 end-to-end traffic between a Mobile Network Node and its 1403 Correspondent Node. 1405 The MNN determines that it is part of a Mobile Network by screening 1406 the Tree Information option in the RA messages from its Attachment 1407 Router. In particular, the MNN knows the TreeDepth as advertised by 1408 the AR. An initial test phase could be derived from MIPv6 to decide 1409 whether optimization with a given CN is possible. 1411 When an MNN performs end-to-end optimization with a CN, the MNN 1412 inserts an empty RRH inside its packets, as opposed to tunneling them 1413 home, which is the default behavior of a Mobile Host as described in 1414 Section 10. The number of slots in the RRH is initially the AR 1415 treeDepth plus 1, but all slots are clear as opposed to the MR 1416 process as described in Section 9. The source address in the header 1417 is the MNN address, and the destination is the CN. 1419 The AR of the MNN is by definition an MR. Since an RRH is already 1420 present in the packet, the MR does not put the packets from the MNN 1421 on its reverse tunnel, but acts as an intermediate MR; it adds the 1422 source address of the packet (the MNN's address) in the RRH (in slot 1423 0) and stamps its careOf instead in the IP header source address 1424 field. Recursively, all the MRs on a nested network trace in path in 1425 the RRH and take over the source IP. 1427 The support required on the CN side extends MIPv6 in a way similar to 1428 the extension that this draft proposes for the HA side. The CN is 1429 required to parse the RRH when it is valid, refresh its BCE 1430 accordingly, and include an RH type 2 with the full path to its 1431 packets to the MNN. 1433 Note that there is no Bind Update between the MNN and the CN. The 1434 RRH must be secured based on tokens exchanged in the test phase. For 1435 the sake of security, it may be necessary to add fields to the RRH or 1436 to add a separate option in the Mobility Header. 1438 A.3 Packet Size Optimization 1440 RRH allows to update the Correspondent BCE on a per packet basis, 1441 which is the highest resolution that we can achieve. While this may 1442 cope with highly mobile and nested configurations, it can also be an 1443 overkill in some situations. 1445 The RRH comes at a cost: it requires processing in all intermediate 1446 Mobile Routers and in the Correspondent Node. Also, a RRH increases 1447 the packet size by more than the size of an IP address per hop in the 1448 Mobile Network. 1450 This is why an additional Routing Header is proposed (type 3). The 1451 semantics of type 3 are very close to type 4 but: 1453 o Type 3 has only one slot, for the Home Address of the source. 1455 o When it can not add the source to the RH type 3 of an outbound 1456 packet, an intermediate MR: 1458 * MR MUST NOT send ICMP (RRH too small) 1459 * MUST NOT put the packet in a reverse tunnel 1461 Rather, it simply overwrites the source and forwards the packet up 1462 the tree as if the RRH had been properly updated. 1464 /* MR processing on outbound packet with RH type 3 support */ 1465 { 1467 if no RH type 3 or 4 in outer header /* First Mobile Router specific */ 1468 or RH type 4 present but saturated { /* Need a nested encapsulation */ 1470 if RRH is saturated { 1471 do ICMP back (RRH too small) 1472 } 1474 /* put packet in sliding reverse tunnel */ 1475 insert new IP header plus RRH 1476 set source address to the MR Home Address 1477 set destination address to the MR Home Agent Address 1478 add an RRH with all slots zeroed out 1479 compute IPsec AH on the resulting packet 1480 } 1482 /* All MRs including first */ 1483 if packet size > MTU { 1484 do ICMP back (Packet too Big) 1485 } else if RRH { 1486 select first free slot in RRH bottom up 1487 set it to source address from IP header 1488 overwrite source address in IP header with MR CareOf 1489 transmit packet 1490 } else if RH type 3 { 1491 if slot 0 is still free { 1492 /* this is end-to-end optimization */ 1493 set it to source address from IP header 1494 } 1495 overwrite source address in IP header with MR CareOf 1496 transmit packet 1497 } 1498 } 1500 o Since the path information is not available, the correspondent 1501 MUST NOT update its BCE based on the RH type 3. The CN (or HA) 1502 identifies the source from the entry in slot 0 and may reconstruct 1503 the initial packet using the CareOf in slot 1 as source for AH 1504 purposes. 1506 A.3.1 Routing Header Type 3 (HAddr option replacement) 1508 This is an RH-based alternative to the Home Address destination 1509 option. Its usage is described in Appendix A.3. 1511 The Type 3 Routing Header has the following format: 1513 0 1 2 3 1514 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 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Next Header | Hdr Ext Len | Routing Type=3| Segments Used | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Reserved | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | | 1521 + + 1522 | | 1523 + Home Address + 1524 | | 1525 + + 1526 | | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 Next Header 1531 8-bit selector. Identifies the type of header immediately 1532 following the Routing header. Uses the same values as the IPv4 1533 Protocol field [13]. 1535 Hdr Ext Len 1537 8-bit unsigned integer. Length of the Routing header in 8-octet 1538 units, not including the first 8 octets. For the Type 3 Routing 1539 header, Hdr Ext Len is always 2. 1541 Routing Type 1543 8-bit unsigned integer. Set to 3. 1545 Segment Used 1547 8-bit unsigned integer. Number of slots used. Either 0 or 1. 1548 When the field is zero, then there is no MR on the path and it is 1549 valid for a CN that does not support RRH to ignore this header. 1551 Reserved 1553 32-bit reserved field. Initialized to zero for transmission; 1554 ignored on reception. 1556 Home Address 1558 128-bit home address of the source of the packet. 1560 The decision to sent RH type 3 or type 4 is up to the source of the 1561 RRH. Several algorithms may apply, one out of N being the simplest. 1563 IPsec HA processing is done as described in Section 11.1 for Type 4. 1565 Appendix B. Multi Homing 1567 B.1 Multi-Homed Mobile Network 1569 Consider difference between situation A and B in this diagram: 1571 ===?== ==?=== 1572 MR1 MR2 1573 | | 1574 ==?=====?== ==?====== situation A 1575 MR3 MR4 MR5 1576 | | | 1577 === === === 1579 ===?== ==?=== 1580 MR1 MR2 1581 | | 1582 ==?=====?=======?====== situation B 1583 MR3 MR4 MR5 1584 | | | 1585 === === === 1587 Going from A to B, MR5 may now choose between MR1 and MR2 for its 1588 Attachment (default) Router. In terms of Tree Information, MR5, as 1589 well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once 1590 MR5 selects its AR, MR2, say, MR5 belongs to the associated tree and 1591 whether MR1 can be reached or not makes no difference. 1593 As long as each MR has a single default router for all its outbound 1594 traffic, 2 different logical trees can be mapped over the physical 1595 configurations in both situations, and once the trees are 1596 established, both cases are equivalent for the processing of RRH. 1598 Note that MR5 MUST use a CareOf based on a prefix owned by its AR as 1599 source of the reverse tunnel, even if other prefixes are present on 1600 the Mobile Network, to ensure that a RH type 2 can be securely routed 1601 back. 1603 B.2 Multihomed Mobile Router 1605 Consider the difference between situation B and C in this diagram: 1607 ===?== ==?=== 1608 MR1 MR2 1609 | | 1610 ==?=====?=======?====== situation B 1611 MR3 MR4 MR5 1612 | | | 1613 === === === 1615 ==? ?== 1616 MR1 1617 | 1618 ==?=====?=======?====== situation C 1619 MR3 MR4 MR5 1620 | | | 1621 === === === 1623 In situation C, MR2's egress interface and its properties are 1624 migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home 1625 Agents, and 2 active interfaces. 1627 If MR1 uses both CareOf addresses at a given point of time, and if 1628 they belong to different prefixes to be used via different attachment 1629 routers, then MR1 actually belongs to 2 trees. It must perform some 1630 routing logic to decide whether to forward packets on either egress 1631 interface. Also, it MUST advertise both tree information sets in its 1632 RA messages. 1634 The difference between situations C and B is that when an attached 1635 router (MR5, say) selects a tree and forwards egress packets via MR1, 1636 it can not be sure that MR1 will actually forward the packets over 1637 that tree. If MR5 has selected a given tree for a specific reason, 1638 then a new source route header is needed to enforce that path on MR1. 1640 The other way around, MR5 may leave the decision up to MR1. If MR1 1641 uses the same attachment router for a given flow or at least a given 1642 destination, then the destination receives consistent RRHs. 1643 Otherwise, the BCE cache will flap, but as both paths are valid, the 1644 traffic still makes it through. 1646 The RRH seems compatible with the various cases of multi-homing 1647 exposed here, though in some cases, some additional work is needed. 1649 Appendix C. Changes from Previous Version of the Draft 1651 This appendix briefly lists some of the major changes in this draft 1652 relative to the previous version of this same draft, draft-thubert- 1653 nemo-reverse-routing-header-00.txt: 1655 Added new Tree Information Option fields: 1657 A 8 bits Bandwidth indication that provides an idea of the 1658 egress bandwidth. 1660 A CRC-32 that changes with the egress path out of the tree. 1662 a 32 bits unsigned integer, built by each MR out of a high 1663 order configured preference and 24 bits random constant. This 1664 can help as a tie break in Attachment Router selection. 1666 Reduced the 'negative' part of the lollipop space to 0..255 1668 Fixed acknowledgements (sorry Patrick :) 1670 Full Copyright Statement 1672 Copyright (C) The Internet Society (2002). All Rights Reserved. 1674 This document and translations of it may be copied and furnished to 1675 others, and derivative works that comment on or otherwise explain it 1676 or assist in its implementation may be prepared, copied, published 1677 and distributed, in whole or in part, without restriction of any 1678 kind, provided that the above copyright notice and this paragraph are 1679 included on all such copies and derivative works. However, this 1680 document itself may not be modified in any way, such as by removing 1681 the copyright notice or references to the Internet Society or other 1682 Internet organizations, except as needed for the purpose of 1683 developing Internet standards in which case the procedures for 1684 copyrights defined in the Internet Standards process must be 1685 followed, or as required to translate it into languages other than 1686 English. 1688 The limited permissions granted above are perpetual and will not be 1689 revoked by the Internet Society or its successors or assigns. 1691 This document and the information contained herein is provided on an 1692 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1693 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1694 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1695 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1696 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1698 Acknowledgement 1700 Funding for the RFC Editor function is currently provided by the 1701 Internet Society.