idnits 2.17.00 (12 Aug 2021) /tmp/idnits2558/draft-thubert-nemo-reverse-routing-header-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 8 instances of too long lines in the document, the longest one being 8 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 599: '...e RH type 0, and the RH type 0 MUST be...' RFC 2119 keyword, line 643: '...es the RRH. The Proposed Size MUST be...' RFC 2119 keyword, line 644: '...current size and MUST NOT be larger th...' RFC 2119 keyword, line 653: '...stination and it MUST NOT forward it t...' RFC 2119 keyword, line 790: '... field MUST be 5....' (15 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 (June 19, 2002) is 7276 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 542, but not defined == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: A later version (-01) exists of draft-ernst-monet-terminology-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-03) exists of draft-kniveton-mobrtr-01 -- 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 (~~), 6 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: December 18, 2002 Cisco Systems 5 June 19, 2002 7 IPv6 Reverse Routing Header and its application to Mobile Networks 8 draft-thubert-nemo-reverse-routing-header-00 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 December 18, 2002. 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 . . . . . . . . . . . . . . . . . . . . 20 69 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 22 70 9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . . 22 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 Full Copyright Statement . . . . . . . . . . . . . . . . . . 38 93 1. Introduction 95 This document assumes the reader is familiar with the Mobile Networks 96 terminology defined in [2] and with Mobile IPv6 defined in [1]. 98 Generally a NEMO may be either simple (a network with one mobile 99 router) or nested, single or multi-homed. This proposal starts from 100 the assumption that nested NEMOs will be the norm, and so presents a 101 solution that avoids the tunnel within tunnel overhead of already 102 existing proposals. 104 The solution is based on a single bi-directional tunnel between the 105 first Mobile Router (MR) to forward a packet and its Home Agent (HA). 106 By using IPsec ESP on that tunnel, home equivalent privacy is 107 obtained without further encapsulation. 109 The solution uses a new Routing Header (RH), called the Reverse 110 Routing Header (RRH), to provide an optimized path for the single 111 tunnel. RRH is a variant of IPv4 Loose Source and Record Route 112 (LSRR) [6] adapted for IPv6. RRH records the route out of the nested 113 NEMO and can be trivially converted into a routing header for packets 114 destined to the NEMO. 116 This version focuses on single-homed NEMOs. Hints for further 117 optimizations and multi-homing are given in the appendixes. 119 Local Fixed Node (LFN) and Correspondent Node (CN) operations are 120 left unchanged as in [1]. Specifically the CN can also be a LFN. 122 Section 3 proposes an example to illustrate the operation of the 123 proposed solution, leaving detailed specifications to the remaining 124 chapters. The reader may refer to Section 2.1 for the specific 125 terminology. 127 1.1 Extending existing solutions 129 This proposal extends [1] to support simple and nested Mobile 130 Networks. 132 This paper also builds on an other existing proposal, [3], which is 133 based on nested tunnels, in order to address the following problems, 134 introduced by that solution: 136 "Pinball" routing 138 Both inbound and outbound packets will flow via the HAs of all the 139 MRs on their path within the NEMO, with increased latency, less 140 resilience and more bandwidth usage. 142 Packet size 144 An extra IPv6 header is added per level of nesting to all the 145 packets. The header compression suggested in [5] cannot be 146 applied because both the source and destination (the intermediate 147 MR and its HA), are different hop to hop. 149 2. Terminology and Assumptions 151 2.1 Terminology 153 Simple NEMO 155 One or more IP subnets attached to a MR and mobile as a unit, with 156 respect to the rest of the Internet. A simple NEMO can be either 157 single or multi-homed. 159 The IP subnets may have any kind of topology and may contain fixed 160 routers. All the access points of the NEMO (to which further MRs 161 may attach) are on the same layer 2 link of the MR. 163 We like to represent a simple single-homed NEMO as an hanger, 164 because it has only one uplink hook and a bar to which multiple 165 hooks can be attached. Graphically we use the question mark "?" 166 to show the uplink hook (interface) connected to the MR, and the 167 "=" sign to represent the bar: 169 ? 170 MR1 171 | 172 =============== 174 Nested NEMO 176 A group of simple NEMOs recursively attached together and 177 implementing nested Mobility as defined in [2]. 179 ? 180 MR1 181 | 182 ====?===============?==== 183 MR2 MR3 184 | | 185 =========== ===?==========?=== 186 MR4 MR5 187 | | 188 ========== ============ 190 IPv6 Mobile Host 192 A IPv6 Host, with support for MIPv6 MN, and the additional Nemo 193 capability described in this draft. 195 Home prefix 197 Network prefix, which identifies the home link within the Internet 198 topology. 200 NEMO prefix 202 Network prefix, common to all IP addresses in the NEMO when the MR 203 is attached to the home link. It may or may not be a subset of 204 the Home subnet prefix. 206 Inbound direction: 208 direction from outside the NEMO to inside 210 Outbound direction: 212 direction from inside the NEMO to outside 214 2.2 Assumptions 216 We make the following assumptions: 218 1. A MR has one Home Agent and one Home Address -> one primary CoA. 220 2. A MR attaches to a single Access Router as default router. 222 3. A MR may have more than one uplink interface. 224 4. An interface can be either wired or wireless. The text assumes 225 that interfaces are wireless for generality. 227 5. Each simple NEMO may have more that one L2 Access Point, all of 228 them controlled by the same Access Router, which we assume to be 229 the Mobile Router. 231 Since an MR has only one primary CoA, only one uplink interface can 232 be used at a given point of time. Since the MR attaches to a single 233 access router, if due care is applied to avoid loops, then the 234 resulting topology is a tree. 236 3. An Example 238 The nested NEMO in the following figure has a tree topology, 239 according to the assumptions in Section 2.2. In the tree each node 240 is a simple NEMO, represented by its MR. 242 +---------------------+ 243 | Internet |---CN 244 +---------------|-----+ 245 / Access Router 246 MR3_HA | 247 ======?====== 248 MR1 249 | 250 ====?=============?==============?=== 251 MR5 MR2 MR6 252 | | | 253 =========== ===?========= ============= 254 MR3 255 | 256 ==|=========?== <-- NEMO3 257 LFN1 MR4 258 | 259 ========= 261 An example nested NEMO 263 This example focuses on a NEMO node at depth 3 (NEMO3) inside the 264 tree, represented by its mobile router MR3. The path to the Top 265 Level Mobile Router (TLMR) MR1 and then the Internet is 267 MR3 -> MR2 -> MR1 -> Internet 269 Consider the case where a LFN belonging to NEMO3 sends a packet to a 270 CN in the Internet, and the CN replies back. 272 With the tunnel within tunnel approach described by [3], we would 273 have three bi-directional nested tunnels: 275 -----------. 276 --------/ /-----------. 277 -------/ | | /----------- 278 CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN 279 MR3_HA -------\ | | \----------- MR3 280 MR2_HA --------\ \----------- MR2 281 MR1_HA ----------- MR1 283 Depending on the relative location of MR1_HA, MR2_HA and MR3_HA, this 284 may lead to a very inefficient "pinball" routing. 286 On the other hand, with the RRH approach we would have only one bi- 287 directional tunnel: 289 --------------------------------- MR1 ---- MR2 ---- 290 CN ------( - - - - - - - - - - - - - - - - (-------- LFN 291 MR3_HA --------------------------------- MR1 ---- MR2 ---- MR3 293 The first mobile router on the path, MR3, in addition to tunneling 294 the packet to its HA, adds a reverse routing header with N = 3 pre- 295 allocated slots. Choosing the right value for N is discussed in 296 Section 6.2. The bottom slot is equivalent to the MIPv6 Home Address 297 option. MR3 inserts its home address MR3_HAddr into slot 0. 299 The outer packet has source MR3's CareOf Address (CoA), MR3_CoA and 300 destination MR3's Home Agent, MR3_HA: 302 <-------------- outer IPv6 header --------------------> 303 +-------+-------++ -- ++----+-------+-------+---------+ +------- 304 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 305 |MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HAddr| |iPACKET 306 | | |: :| 4 | | | | | 307 +-------+-------++ -- ++----+-------+-------+---------+ +------- 309 The second router on the path, MR2, notices that the packet already 310 contains an RRH, and so it overwrites the source address of the 311 packet with its own address, MR2_CoA, putting the old source address, 312 MR3_CoA, in the first free slot of the RRH. 314 The outer packet now has source MR2_CoA and destination MR3_HA; the 315 RRH from top to bottom is MR3_CoA | MR3_HAddr: 317 <-------------- outer IPv6 header --------------------> 318 +-------+-------++ -- ++----+-------+-------+---------+ +------- 319 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 320 |MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA|MR3_HAddr| |iPACKET 321 | | |: :| 4 | | | | | 322 +-------+-------++ -- ++----+-------+-------+---------+ +------- 323 In general the process followed by the second router is repeated by 324 all the routers on the path, including the TLMR (in this example 325 MR1). When the packet leaves MR1 the source address is MR1_CoA and 326 the RRH is MR2_CoA | MR3_CoA | MR3_HAddr: 328 <-------------- outer IPv6 header --------------------> 329 +-------+-------++ -- ++----+-------+-------+---------+ +------- 330 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 331 |MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HAddr| |iPACKET 332 | | |: :| 4 | | | | | 333 +-------+-------++ -- ++----+-------+-------+---------+ +------- 335 In a colloquial way we may say that while the packet travels from MR3 336 to MR3_HA, the NEMO tunnel end point "telescopes" from MR3 to MR2 to 337 MR1. 339 When the home agent MR3_HA receives the packet it notices that it 340 contains a RRH and it looks at the bottom entry, MR3_HAddr. This 341 entry is used as if it were a MIPv6 Home Address destination option, 342 i.e. as an index into the Binding Cache. When decapsulating the 343 inner packet the home agent performs the checks described in Section 344 8, and if successful it forwards the inner packet to CN. 346 MR3_HA stores two items in the Bind Cache Entry associated with MR3: 347 the address entries from RRH, to be used to build the RH, and the 348 packet source address MR1_CoA, to be used as the first hop. 350 Further packets from the CN to the LFN are plain fixed IPv6 packets. 351 Destination is LFN, and so the packet reaches MR3's home network. 353 MR3_HA intercepts it, does a Bind Cache prefix lookup and obtains as 354 match the MR3 entry, containing the first hop and the information 355 required to build the RH. It then puts the packet in the tunnel 356 MR3_HA -- MR3 as follows: source address MR3_HA and destination 357 address the first hop, MR1_CoA. The RH is trivially built out of the 358 previous RRH: MR2_CoA | MR3_CoA | MR3_HAddr: 360 <-------------- outer IPv6 header --------------------> 361 +-------+-------++ -- ++----+-------+-------+---------+ +------- 362 |oSRC |oDST |: :|oRH | | | | | 363 |MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HAddr| |iPACKET 364 | | |: :| 2 | | | | | 365 +-------+-------++ -- ++----+-------+-------+---------+ +------- 366 The packet is routed with plain IP routing up to the first 367 destination MR1_CoA. 369 The RH of the outer packet is type 2 as in [1], but has additional 370 semantics inherited from type 0: it contains the path information to 371 traverse the nested NEMO from the TLMR to the tunnel endpoint MR. 372 Each intermediate destination forwards the packet to the following 373 destination in the routing header. The security aspects of this are 374 treated in Section 11.2. 376 MR1, which is the initial destination in the IP header, looks at the 377 RH and processes it according to Section 9, updating the RH and the 378 destination and sending it to MR2_CoA. MR2 does the same and so on 379 until the packet reaches the tunnel endpoint, MR3. 381 When the packet reaches MR3, the source address in the IP header is 382 MR3_HA, the destination is MR3_CoA and in the RH there is one segment 383 left, MR3_HAddr. As a consequence the packet belongs to the MR3_HA - 384 - MR3 tunnel. MR3 decapsulates the inner packet, applying the rules 385 described in Section 9 and sends it to LFN. The packet that reaches 386 LFN is the plain IPv6 packet that was sent by CN. 388 4. New Routing Headers 390 This draft modifies the MIPv6 Routing Header type 2 and introduces 391 two new Routing Headers, type 3 and 4. Type 3 will be discussed in 392 Appendix A.3.1. The draft presents their operation in the context of 393 Mobile Routers although the formats are not tied to MIP and could be 394 used in other situations. 396 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) 398 Mobile IPv6 uses a Routing header to carry the Home Address for 399 packets sent from a Correspondent Node to a Mobile Node. In [1], 400 this Routing header (Type 2) is restricted to carry only one IPv6 401 address. The format proposed here extends the Routing Header type 2 402 to be multi-hop. 404 The processing of the multi-hop RH type 2 inherits from the RH type 0 405 described in [10]. Specifically: the restriction on multicast 406 addresses is the same; a RH type 2 is not examined or processed until 407 it reaches the node identified in the Destination Address field of 408 the IPv6 header; in that node, the RH type 0 algorithm applies, with 409 added security checks. 411 The construction of the multi-hop RH type 2 by the HA is described in 412 Section 8; the processing by the MRs is described in Section 9.5; and 413 the security aspects are treated in Section 11.2. 415 The multi-hop Routing Header type 2, as extended by this draft, has 416 the following format: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Next Header | Hdr Ext Len | Routing Type=2| Segments Left | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Reserved | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | | 426 + + 427 | | 428 + Address[1] + 429 | | 430 + + 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 + + 435 | | 436 + Address[2] + 437 | | 438 + + 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 . . . 442 . . . 443 . . . 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | | 446 + + 447 | | 448 + Address[n] + 449 | | 450 + + 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Next Header 456 8-bit selector. Identifies the type of header immediately 457 following the Routing header. Uses the same values as the IPv4 458 Protocol field [13]. 460 Hdr Ext Len 462 8-bit unsigned integer. Length of the Routing header in 8-octet 463 units, not including the first 8 octets. For the Type 2 Routing 464 header, Hdr Ext Len is equal to two times the number of addresses 465 in the header. 467 Routing Type 469 8-bit unsigned integer. Set to 2. 471 Segments Left 473 8-bit unsigned integer. Number of route segments remaining, i.e., 474 number of explicitly listed intermediate nodes still to be visited 475 before reaching the final destination. 477 Reserved 479 32-bit reserved field. Initialized to zero for transmission; 480 ignored on reception. 482 Address[1..n] 484 Vector of 128-bit addresses, numbered 1 to n. 486 The destination node of a packet containing a RH type 2 can be a MR 487 or some other kind of node. If it is a MR it will perform the 488 algorithm described in Section 9.5, otherwise it will operate as 489 prescribed by IPv6 [10] when the routing type is unrecognized. 491 4.2 Routing Header Type 4 (The Reverse Routing Header) 493 The Routing Header type 4, or Reverse Routing Header (RRH), is a 494 variant of IPv4 loose source and record route (LSRR) [6] adapted for 495 IPv6. 497 Addresses are added from bottom to top (0 to n-1 in the picture). 498 The RRH is designed to help the destination build an RH for the 499 return path. 501 When a RRH is present in a packet, the rule for upper-layer checksum 502 computing is that the source address used in the pseudo-header is 503 that of the original source, located in the slot 0 of the RRH, unless 504 the RRH slot 0 is empty, in which case the source in the IP header of 505 the packet is used. 507 As the 'segment left' field of the generic RH is reassigned to the 508 number of segments used, a IPv6 Host that does not support RRH will 509 discard the packet, unless the RRH is empty. 511 The Type 4 Routing Header has the following format: 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Next Header | Hdr Ext Len | Routing Type=4| Segments Used | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Sequence Number | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | | 521 + + 522 | | 523 + Slot[n-1] + 524 | | 525 + + 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 . . . 529 . . . 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | 532 + + 533 | | 534 + Slot[1] (1st MR CoA) + 535 | | 536 + + 537 | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 + + 541 | | 542 + Slot[0] (Home address) + 543 | | 544 + + 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Next Header 550 8-bit selector. Identifies the type of header immediately 551 following the Routing header. Uses the same values as the IPv4 552 Protocol field [13]. 554 Hdr Ext Len 556 8-bit unsigned integer. Length of the Routing header in 8-octet 557 units, not including the first 8 octets. For the Type 4 Routing 558 header, Hdr Ext Len is equal to two times the number of addresses 559 in the header. 561 Routing Type 563 8-bit unsigned integer. Set to 4. 565 Segments Used 567 8-bit unsigned integer. Number of slots used. Initially set to 1 568 by the MR when only the Home Address is there. Incremented by the 569 MRs on the way as they add the packets source addresses to the 570 RRH. 572 Sequence Number 574 32-bit unsigned integer. The Sequence Number starts at 0, and is 575 incremented by the source upon each individual packet. Using the 576 lollipop algorithm, the high order byte is never reset to zero but 577 passes from 255 to 1. 579 The sequence number is used to check the freshness of the RRH; 580 anti-replay protection is left to IPsec AH. 582 Slot[n-1..0] 584 Vector of 128-bit addresses, numbered n-1 to 0. 586 When applied to the NEMO problem, the RRH can be used to update the 587 HA on the actual location of the MR. Only MRs forwarding packets on 588 an egress interface while not at home update it on the fly. 590 A RRH is inserted by the first MR on the Nemo outbound path, as part 591 of the reverse tunnel encapsulation; it is removed by the associated 592 HA when the tunneled packet is decapsulated. The RRH contains n pre- 593 allocated address slots, to be filled by each MR in the path. 595 4.3 Extension Header order 597 The RH type 2 is to be placed as any RH as described in [10] section 598 4.1. If a RH type 0 is present in the packet, then the RH type 2 is 599 placed immediately after the RH type 0, and the RH type 0 MUST be 600 consumed before the RH type 2. 602 RH type 3 and 4 are mutually exclusive. They are to be placed right 603 after the Hop-by-Hop Options header if any, or else right after the 604 IPv6 header. 606 As a result, the order prescribed in section 4.1 of RFC 2460 becomes: 608 IPv6 header 610 Hop-by-Hop Options header 612 Routing header type 3 or 4 614 Destination Options header (note 1) 616 Routing header type 0 618 Routing header type 2 620 Fragment header 622 Authentication header (note 2) 624 Encapsulating Security Payload header (note 2) 626 Destination Options header (note 3) 628 upper-layer header 630 5. ICMP 632 The RRH could have fewer slots than the number of MRs in the path 633 because either the nested NEMO topology is changing too quickly or 634 the MR that inserted the RRH could have a wrong representation of the 635 topology. 637 To solve this problem a new ICMP message is introduced, "RRH 638 Warning", type 64. Note that this ICMP message creates a new class 639 of warning messages besides the error messages and the control 640 messages of ICMP. 642 This message allows a MR on the path to propose a larger number of 643 slots to the MR that creates the RRH. The Proposed Size MUST be 644 larger than the current size and MUST NOT be larger than 8. 646 The originating MR must rate-limit the ICMP messages to avoid 647 excessive ICMP traffic in the case of the source failing to operate 648 as requested. 650 The originating MR must insert an RH type 2 based on the RRH in the 651 associated IP header, in order to route the ICMP message back to the 652 source of the reverse tunnel. A MR that receives this ICMP message 653 is the actual destination and it MUST NOT forward it to the (LFN) 654 source of the tunneled packet. 656 The type 64 ICMP has the following format: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Type = 64 | Code = 0 | Checksum | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Current Size | Proposed Size | Reserved | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | As much of invoking packet | 666 + as will fit without the ICMPv6 packet + 667 | exceeding the minimum IPv6 MTU | 668 . . 669 . . 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Type 674 64 [To Be Assigned] 676 Code 0: RRH too small 678 The originating MR requires the source to set the RRH size to a 679 larger value. The packet that triggered the ICMP will still be 680 forwarded by the MR, but the path cannot be totally optimized (see 681 Section 9.3). 683 Checksum 685 The ICMP checksum [12]. 687 Current Size 689 RRH size of the invoking packet, as a reference. 691 Proposed Size 693 The new value, expressed as a number of IPv6 addresses that can 694 fit in the RRH. 696 Reserved 698 16-bit reserved field. Initialized to zero for transmission; 699 ignored on reception. 701 6. Modifications to IPv6 Neighbor Discovery 703 6.1 Modified Router Advertisement Message Format 705 Mobile IPv6 [1] modifies the format of the Router Advertisement 706 message [11] by the addition of a single flag bit (H) to indicate 707 that the router sending the Advertisement message is serving as a 708 home agent on this link. 710 This draft adds another single flag bit (R) to indicate that the 711 router sending the advertisement message is a MR. This means that 712 the link on which the message is sent is a NEMO, which may or may not 713 be at home. 715 The Router Advertisement message has the following format: 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type | Code | Checksum | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Reachable Time | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Retrans Timer | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Options ... 729 +-+-+-+-+-+-+-+-+-+-+-+- 731 This format represents the following changes over that originally 732 specified for Neighbor Discovery [11]: 734 Home Agent (H) 736 The Home Agent (H) bit is set in a Router Advertisement to 737 indicate that the router sending this Router Advertisement is also 738 functioning as a Mobile IP home agent on this link. 740 NEMO Capable (N) 742 The NEMO Capable (N) bit is set in a Router Advertisement to 743 indicate that the router sending this Router Advertisement is also 744 functioning as a Mobile Router on this link, so that the link is a 745 NEMO, possibly away from home. 747 Reserved 748 Reduced from a 6-bit field to a 4-bit field to account for the 749 addition of the Home Agent (H) and the Nemo Capable (N) bits. 751 6.2 New Tree Information Option Format 753 This draft defines a new Tree Information option, used in Router 754 Advertisement messages. 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 | Preference | TreeDepth | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |F|H| Reserved | DelayTime | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 + + 767 | | 768 + Tree TLMR Identifier + 769 | | 770 + + 771 | | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | | 774 + + 775 | | 776 + Tree Group + 777 | | 778 + + 779 | | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Type 784 Set to 7. 786 Length 788 8-bit unsigned integer. The length of the option (including the 789 type and length fields) in units of 8 octets. The value of this 790 field MUST be 5. 792 Preference 794 8-bit signed integer. The preference of a tree as configured on 795 its TLMR. Range from 0 = lowest to 255 = maximum. 797 TreeDepth 799 8-bit signed integer. Set to 0 by the TLMR and incremented by 1 800 by each MR down the tree. 802 Fixed (F) 804 1-bit flag. Set to indicate that the TLMR is either attached to a 805 fixed network or at home. This field is set by the TLMR and left 806 unchanged by the other MRs. 808 Home (H) 810 1-bit flag. Set to indicate that the TLMR is also functioning as 811 a HA, for re-homing purposes. Set by the TLMR and left unchanged 812 by the other MRs. 814 Reserved 816 14-bit reserved field. Initialized to zero for transmission; 817 ignored on reception. 819 DelayTime 821 Tree-wide time constant in milliseconds, set by the TLMR and left 822 unchanged by other MRs. 824 Tree TLMR Identifier 826 Set by the TLMR and left unchanged by other MRs. Identifier of 827 the tree. It is a unique IPv6 address. 829 Tree Group 831 Group Identifier. Set by the TLMR and left unchanged by other 832 MRs. A MR may use the Tree Group in its tree selection algorithm. 834 The TLMR MUST include this option in its Router Advertisements. 836 A MR receiving this option from its Access Router MUST update the 837 TreeDepth field and MUST forward it on its ingress interface(s), as 838 described in Section 9.4. 840 The alignment requirement of the Tree Information Option is 8n. 842 7. Binding Cache Management 844 7.1 Binding Updates 846 Binding Updates are still used as described in MIPv6 [1] for Home 847 Registration and de-registration, but only when the MR registers for 848 the first time with its HA. 850 Since the BU doesn't contain the full NEMO path to the MR, it cannot 851 be used in this design of nested NEMOs. 853 7.2 RRH Heartbeat 855 Subsequent updates (or just refreshes) to the CoA binding are 856 obtained as one of the results of processing the RRH by the HA. 858 When the MR becomes aware of a topology change in the tree (for 859 examples it changes point of attachment, it obtains a new CoA, it 860 receives a Tree Information message) or in the absence of traffic 861 (detected by a timeout) to the HA, it must send an RRH Heartbeat (IP 862 packet with the RRH and empty payload). 864 Security issues are discussed in Section 11.2. 866 8. Home Agent Operation 868 This section inherits from chapter 10 [1], which is kept unmodified 869 except for parts 10.5 and 10.6 which are extended. This draft mostly 870 adds the opportunity for an MN to update the Binding Cache of its 871 Home Agent using RRH, though it does not change the fact that MNs 872 still need to select a home agent, register and deregister to it, 873 using the MIP Bind Update. 875 This draft extends [1] section 10.6 as follows: 877 o The entry point of the tunnel is now checked against the TLMR as 878 opposed to the primary CoA. 880 o The Binding Cache can be updated based on RRH with proper AH 881 authentication. 883 As further explained in Section 7.1, this specification modifies MIP 884 so that HA can rely on the RH type 4 (RRH) to update its the Bind 885 Cache Entry (BCE), when the Mobile Node moves. The conceptual 886 content of the BCE is extended to contain a sequence counter, and the 887 sequence of hops within the -potentially nested- Mobile Network to a 888 given Mobile Node. The sequence counter is initially set to 0. 890 When the HA gets a packet destined to itself, it checks for the 891 presence of a Routing Header of type 3 or 4. Both contain as least 892 the entry for the home address of the MN in slot 0; this replaces the 893 MIP Home Address Option and allows the HA to determine the actual 894 source of the packet, to access the corresponding security 895 association. 897 As explained in Section 11.2, the HA MUST verify the authenticity of 898 the packet using IPSEC AH and drop packets that were not issued by 899 the proper Mobile Node. An RRH is considered only if the packet is 900 authenticated and if its sequence number is higher than the one saved 901 in the BCE. Also, an RRH is considered only if an initial Bind 902 Update exchange has been successfully completed between the Mobile 903 Node and its Home Agent for Home Registration. If the RRH is valid, 904 then the Bind Cache Entry is revalidated for a lifetime as configured 905 from the initial Bind Update. 907 The BCE abstract data is updated as follows: 909 The first hop for the return path is the last hop on the path of 910 the incoming packet, that is between the HA and the Top Level 911 Mobile Router (TLMR) of the Mobile Network. The HA saves the IP 912 address of the TLMR from the source field in the IP header. 914 The rest of the path to the MN is found in the RRH. 916 The sequence counter semantics is changed as described in Section 917 4.2 919 This draft extends [1] section 10.5 as follows: 921 A Home Agent advertises the prefixes of its registered Mobile 922 Routers, during the registration period, on the local Interior 923 Gateway Protocol (IGP). 925 The Routing Header type 2 is extended to be multi-hop. 927 The Home Agent is extended to support routes to prefixes that are 928 owned by Mobile Routers. This can be configured statically, or can 929 be exchanged using a routing protocol as in [3], which is out of the 930 scope of this document. As a consequence of this process, the Home 931 Agent which is selected by a Mobile Router advertises reachability of 932 the MR prefixes for the duration of the registration over the local 933 IGP. 935 When a HA gets a packet for which the destination is a node behind a 936 Mobile Router, it places the packet in the tunnel to the associated 937 MR. This ends up with a packet which destination address in the IP 938 Header is the TLMR, and with a Routing Header of type 2 for the rest 939 of the way to the Mobile Router, which may be multi-hop. 941 To build the RH type 2 from the RRH, the HA sets the type to 2, and 942 clears the bits 32-63 (byte 4 to 7). 944 9. Mobile Router Operation 946 This section inherits from chapter 11 of [1], which is extended to 947 support Mobile Networks and Mobile Routers as a specific case of 948 Mobile Node. 950 This draft extends section 11.2.1 of [1] as follows: 952 o When not at home, an MR uses a reverse tunnel with its HA for all 953 the traffic that is sourced in its mobile network(s); traffic 954 originated further down a nested network is not tunneled twice but 955 for exception cases. 957 o The full path to and within the Mobile Network is piggy-backed 958 with the traffic on a per-packet basis to cope with rapid 959 movement. This makes the packet construction different from 960 MIPv6. 962 The MR when not at home sets up a bi-directional tunnel with its HA. 963 The reverse direction MR -> HA is needed to assure transparent 964 topological correctness to LFNs, as in [3]. But, as opposed to that 965 solution, nested tunnels are generally avoided. 967 9.1 Processing of ICMP "RRH too small" 969 The New ICMP message "RRH too Small" is presented in Section 5. This 970 message is addressed to the MR which performs the tunnel 971 encapsulation and generates the RRH. 973 Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate 974 it to the originating LFN or inner tunnel source, but MUST process it 975 for itself. 977 If the Current Size in the ICMP messages matches the actual current 978 number of slots in RRH, and if the ICMP passes some safety checks as 979 described in Section 5, then the MR MAY adapt the number of slots to 980 the Proposed Size. 982 9.2 Processing of ICMP error 984 ICMP back { 986 if RRH is present { 987 compute RH type 2 based on RRH 988 get packet source from IP header 989 send ICMP error to source including RH type 2. 990 } 991 else { 992 get packet source from IP header 993 send ICMP error to source with no RH. 994 } 995 } 997 When the MR receives an ICMP error message, it checks whether it is 998 the final destination of the packet by looking at the included 999 packet. If the included packet has an RRH, then the MR will use the 1000 RRH to forward the ICMP to the original source of the packet. 1002 9.3 Processing of RHH for Outbound Packets 1004 if no RRH in outer header /* First Mobile Router specific */ 1005 or RRH present but saturated { /* Need a nested encapsulation */ 1007 if RRH is saturated { 1008 do ICMP back (RRH too small) 1009 } 1011 /* put packet in sliding reverse tunnel */ 1012 insert new IP header plus RRH 1013 set source address to the MR Home Address 1014 set destination address to the MR Home Agent Address 1015 add an RRH with all slots zeroed out 1016 compute IPsec AH on the resulting packet 1017 } 1019 /* All MRs including first */ 1020 if packet size <= MTU { 1021 select first free slot in RRH bottom up 1022 set it to source address from IP header 1023 overwrite source address in IP header with MR CareOf 1024 transmit packet 1025 } else { 1026 do ICMP back (Packet too Big) 1027 } 1029 If the packet already contains an RRH in the outer header, and has a 1030 spare slot, the MR adds the source address from the packet IP header 1031 to the RRH and overwrites the source address in the IP header with 1032 its CoA. As a result, the packets are always topologically correct. 1034 Else, if the RRH is present but is saturated, and therefore the 1035 source IP can not be added, the MR sends a ICMP 'RRH too small' to 1036 the tunnel endpoint which originated the outer packet, using the RRH 1037 info to route it back. The ICMP message is a warning, and the packet 1038 is not discarded. Rather, the MR does a nested encapsulation of the 1039 packet in its own reverse tunnel home with an additional RRH. 1041 Else, if the packet does not have an RRH, the MR puts it in its 1042 reverse tunnel, sourced at the CoA, with an RRH indicating in slot 0 1043 the Home Address of the MR, and with proper IPsec AH as described 1044 further in Section 11.1. 1046 9.4 Processing of Tree Information Option 1048 The Tree Information Option in Router Advertisement messages allows 1049 the Mobile Router to select a tree and learn about its capabilities. 1051 The treeDepth can be used to compute the optimum number of slots in 1052 the RRH. 1054 The Option contains an entry for the home address in slot 0, and one 1055 for every CareOf on the way but that of the last Mobile Router 1056 (TLMR). As the TLMR sets the treeDepth to 0 and each MR increments 1057 it on the way down the tree, the optimum number of slots is normally 1058 (treeDepth+1), where treeDepth is the depth advertised by the MR over 1059 its Mobile Networks. 1061 9.5 Processing of the extended Routing Header Type 2 1063 if Segments Left = 0 { 1065 /* new check: packet must be looped back internally */ 1066 if packet doesn't come from a loopback interface { 1067 discard the packet 1068 return 1069 } 1071 proceed to process the next header in the packet, whose type is 1072 identified by the Next Header field in the Routing header 1073 } 1074 else if Hdr Ext Len is odd { 1075 send an ICMP Parameter Problem, Code 0, message to the Source 1076 Address, pointing to the Hdr Ext Len field, and discard the 1077 packet 1078 } 1079 else { 1080 compute n, the number of addresses in the Routing header, by 1081 dividing Hdr Ext Len by 2 1083 if Segments Left is greater than n { 1084 send an ICMP Parameter Problem, Code 0, message to the Source 1085 Address, pointing to the Segments Left field, and discard the 1086 packet 1087 } 1088 else { 1089 decrement Segments Left by 1; 1091 compute i, the index of the next address to be visited in 1092 the address vector, by subtracting Segments Left from n 1094 if Address [i] or the IPv6 Destination Address is multicast { 1095 discard the packet 1096 } 1097 else { 1098 /* new security check */ 1099 if Address [i] doesn't belong to one of the NEMO prefixes { 1100 discard the packet 1101 return 1102 } 1104 /* new check: keep MIPv6 behavior: prevent packets from being 1105 * forwarded outside the node. 1106 */ 1107 if Segments Left equals 0 and Address[i] isn't the node's own 1108 home address { 1109 discard the packet 1110 return 1111 } 1112 swap the IPv6 Destination Address and Address[i] 1114 if the IPv6 Hop Limit is less than or equal to 1 { 1115 send an ICMP Time Exceeded -- Hop Limit Exceeded in 1116 Transit message to the Source Address and discard the 1117 packet 1118 } 1119 else { 1120 decrement the Hop Limit by 1 1122 resubmit the packet to the IPv6 module for transmission 1123 to the new destination; 1124 } 1125 } 1126 } 1127 } 1129 9.6 Decapsulation 1131 A MR when decapsulating a packet from its HA must perform the 1132 following checks 1134 1. Destination address 1136 The destination address of the inner packet must belong to one of 1137 the NEMO prefixes. 1139 10. Mobile Host Operation 1141 When it is at Home, a Mobile Host issues packets with source set to 1142 its home address and with destination set to its CN, in a plain IPv6 1143 format. 1145 When a MH is not at home but is attached to a foreign link in the 1146 Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to 1147 manage its mobility. 1149 When a MH is visiting a foreign Mobile Network, it forwards its 1150 outbound packets over the reverse tunnel (including RRH) to its HA. 1151 One can view that operation as a first MR process applied on a plain 1152 IPv6 packet issued by an LFN. 1154 As a result, the encapsulating header include: 1156 with source set to the MH COA and destination set to the MH HA 1158 with slot 0 set to the MH Home Address 1160 The inner packet is the plain IPv6 packet from the MH Home Address to 1161 the CN. 1163 11. Security Considerations 1165 This section is not complete; further work is needed to analyse and 1166 solve the security problems of record and source route. 1168 Compared to MIPv6, the main security problem seems to be the fact 1169 that the RRH can be modified in transit by an in-axis attacker. It 1170 has to be noted that an in-axis attacker (for example any MR in the 1171 NEMO) can perform more effective attacks than modifying the RRH. 1173 Selecting the tree to attach to is a security critical operation 1174 outside of the scope of this draft. 1176 11.1 IPsec Processing 1178 The IPsec [7] AH [8] and ESP [9] can be used in tunnel mode to 1179 provide different security services to the tunnel between a MR and 1180 its HA. ESP tunnel mode SHOULD be used to provide confidentiality 1181 and authentication to the inner packet. AH tunnel mode MUST be used 1182 to provide authentication of the outer IP header fields, especially 1183 the RH. 1185 The Routing Header Type 2 is treated as Type 0, namely as mutable but 1186 predictable [8], and so will be included in the Authentication Data 1187 calculation. As per IPsec, the sender must order the field so that 1188 it appears as it will at the receiver, prior to performing the 1189 Integrity Check Value (ICV) computation. 1191 The Routing Header Type 4 is "partially mutable", and as such can be 1192 included in the Authentication Data calculation. Given the way Type 1193 4 is processed, the sender cannot order the field so that it appears 1194 as it will at the receiver; this means the receiver will have to 1195 shuffle the fields. 1197 The sender (the MR) will zero out all the slots and the Segment Used 1198 field of the RRH, and will put as source address of the outer packet 1199 its Home Address, and then will perform the ICV computation. 1201 The receiver (the HA) will put the entry in slot 0 (the MR Home 1202 Address) in the source address and will zero out all the slots and 1203 the Segment Used field of the RRH, and then will perform the ICV 1204 verification. 1206 11.2 New Threats 1208 The RH type 4 is used to construct a MIPv6 RH type 2 with additional 1209 semantics, as described in Section 4.1. Since RH type 2 becomes a 1210 multi hop option like RH type 0, care must be applied to avoid the 1211 spoofing attack that can be performed with the IPv4 source route 1212 option. This is why IPv6 [10] takes special care in responding to 1213 packets carrying Routing Headers. 1215 AH authenticates the MR Home Address identity and the RRH sequence 1216 number. The RRH sequence number is to be used to check the freshness 1217 of the RRH; anti-replay protection can be obtained if the receiver 1218 enables the anti-replay service of AH [8]. 1220 As a consequence, the only kind of successful attack seems to require 1221 to be able to modify the packet in flight. 1223 If one of the RRH entry is faked either to an address outside the 1224 tree or to an address that doesn't match the tree topology (not 1225 belonging to one of the NEMO prefixes at that level) then the reply 1226 packet containing a RH type 2 built out of the previous RRH will be 1227 dropped by the first MR that processes that entry, as described in 1228 Section 9. 1230 It is still an issue how to validate that the source of the outer 1231 packet is the actual TLMR as opposed to a forged IP address put by an 1232 on-axis attacker outside the NEMO. 1234 12. Acknowledgements 1236 The authors wish to thank Steve Deering, Fred Baker, Thomas Fossati, 1237 Dave Auerbach, Kent Leung, Francois Le Faucheur, Dana Blair, Dan 1238 Shell, Dave Forster and Massimo Lucchina for their constructive 1239 comments on the ideas that sustain this document. 1241 References 1243 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 1244 IPv6", draft-ietf-mobileip-ipv6-17 (work in progress), May 1245 2002. 1247 [2] Ernst, T., "Network Mobility Support Terminology", draft-ernst- 1248 monet-terminology-00 (work in progress), February 2002. 1250 [3] Kniveton, T., "Mobile Router Support with Mobile IP", draft- 1251 kniveton-mobrtr-01 (work in progress), March 2002. 1253 [4] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A. 1254 Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix 1255 Scope Binding Updates)", draft-ernst-mobileip-v6-network-03 1256 (work in progress), March 2002. 1258 [5] Deering, S. and B. Zill, "Redundant Address Deletion when 1259 Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr- 1260 deletion-00 (work in progress), November 2001. 1262 [6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1263 1981. 1265 [7] Kent, S. and R. Atkinson, "Security Architecture for the 1266 Internet Protocol", RFC 2401, November 1998. 1268 [8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1269 November 1998. 1271 [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1272 (ESP)", RFC 2406, November 1998. 1274 [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1275 Specification", RFC 2460, December 1998. 1277 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1278 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1280 [12] Conta, A. and S. Deering, "Internet Control Message Protocol 1281 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1282 Specification", RFC 2463, December 1998. 1284 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 1285 line Database", RFC 3232, January 2002. 1287 Authors' Addresses 1289 Pascal Thubert 1290 Cisco Systems Technology Center 1291 Village d'Entreprises Green Side 1292 400, Avenue Roumanille 1293 Biot - Sophia Antipolis 06410 1294 FRANCE 1296 EMail: pthubert@cisco.com 1298 Marco Molteni 1299 Cisco Systems Technology Center 1300 Village d'Entreprises Green Side 1301 400, Avenue Roumanille 1302 Biot - Sophia Antipolis 06410 1303 FRANCE 1305 EMail: mmolteni@cisco.com 1307 Appendix A. Optimizations 1309 A.1 Prefix Scope Binding Updates 1311 [4] suggests modifications to MIPv6 to enable support for LFNs in 1312 non-nested NEMOs, leaving for later investigation more complex 1313 scenarios like MNs behind the MR or nested NEMOs. 1315 The solution described there has bi-directional route optimization as 1316 in MIPv6: the CN to MR direction uses the RH type 2, while the MR to 1317 CN direction uses the home address destination option. Route 1318 optimization is obtained by introducing a new kind of binding update, 1319 the Prefix Scope BU (PSBU) and by modifying the CN and MR operations 1320 in order to exploit it. 1322 The MR has to keep track of all the pending communications between 1323 hosts in his NEMO and their CNs, in order to send to the CNs a PSBU 1324 each time the MR changes its point of attachment. 1326 If we extend [4] in such a way that each MR in a nested NEMO sends a 1327 full set of PSBUs each time it changes its point of attachment, then 1328 each CN by receiving all the PSBUs and processing them can infer a 1329 partial topology of the nested NEMO, sufficient to build a multi-hop 1330 routing header for packets sent to nodes inside the nested NEMO. 1332 However, this extension seems to come at a too high price: 1334 1. PSBU storm 1336 when one MR changes its point of attachment, it needs to send a 1337 PSBU to all the CNs of each node behind him. When the NEMO is 1338 nested, the number of nodes and relative CNs can be huge. In 1339 order to send the PSBUs, the MR has to keep track of all the 1340 traffic it forwards to maintain his list of CNs. 1342 2. CN operation 1344 The computation burden of the CN becomes heavy, because it has to 1345 analyze each PSBU in a recursive fashion in order to deduct 1346 nested NEMO topology required to build a multi hop routing 1347 header. 1349 3. Missing PSBU 1351 If a CN doesn't receive the full set of PSBU sent by the MR, it 1352 will not be able to infer the full path to a node inside the 1353 nested NEMO. The RH will be incomplete and the packet may or may 1354 not be delivered. If PSBU are sent asynchronously by each MR, 1355 then, when the relative position of MRs and/or the TLMR point of 1356 attachment change rapidly, the image of Mobile Network that the 1357 CN maintains is highly unstable. 1359 A conclusion is that the path information must be somehow aggregated 1360 to provide the CN with consistent snapshots of the full path across 1361 the Mobile Network. If this is achieved by a series of stacked Home 1362 Address Options, then the problem turns into a format war and about 1363 the opportunity to insert headers in a packet as opposed to 1364 tunneling. Either way is a route record, which is why defining a 1365 real V6 version of LSRR is relevant in the first place. 1367 A.2 Path Optimization with RRH 1369 The body of the draft presents RRH as a header that circulates in the 1370 reverse tunnel exclusively. The RRH format by itself has no such 1371 limitation. This section illustrates a potential optimization for 1372 end-to-end traffic between a Mobile Network Node and its 1373 Correspondent Node. 1375 The MNN determines that it is part of a Nemo by screening the Tree 1376 Information option in the RA messages from its Access Router. In 1377 particular, the MNN knows the TreeDepth as advertised by the AR. An 1378 initial test phase could be derived from MIPv6 to decide whether 1379 optimization with a given CN is possible. 1381 When an MNN performs end-to-end optimization with a CN, the MNN 1382 inserts an empty RRH inside its packets, as opposed to tunneling them 1383 home, which is the default behavior of a Mobile Host as described in 1384 Section 10. The number of slots in the RRH is initially the AR 1385 treeDepth plus 1, but all slots are clear as opposed to the MR 1386 process as described in Section 9. The source address in the header 1387 is the MNN address, and the destination is the CN. 1389 The AR of the MNN is by definition an MR. Since an RRH is already 1390 present in the packet, the MR does not put the packets from the MNN 1391 on its reverse tunnel, but acts as an intermediate MR; it adds the 1392 source address of the packet (the MNN's address) in the RRH (in slot 1393 0) and stamps its careOf instead in the IP header source address 1394 field. Recursively, all the MRs on a nested network trace in path in 1395 the RRH and take over the source IP. 1397 The support required on the CN side extends MIPv6 in a way similar to 1398 the extension that this draft proposes for the HA side. The CN is 1399 required to parse the RRH when it is valid, refresh its BCE 1400 accordingly, and include an RH type 2 with the full path to its 1401 packets to the MNN. 1403 Note that there is no Bind Update between the MNN and the CN. The 1404 RRH must be secured based on tokens exchanged in the test phase. For 1405 the sake of security, it may be necessary to add fields to the RRH or 1406 to add a separate option in the Mobility Header. 1408 A.3 Packet Size Optimization 1410 RRH allows to update the Correspondent BCE on a per packet basis, 1411 which is the highest resolution that we can achieve. While this may 1412 cope with highly mobile and nested configurations, it can also be an 1413 overkill in some situations. 1415 The RRH comes at a cost: it requires processing in all intermediate 1416 Mobile Routers and in the Correspondent Node. Also, a RRH increases 1417 the packet size by more than the size of an IP address per hop in the 1418 Mobile Network. 1420 This is why an additional Routing Header is proposed (type 3). The 1421 semantics of type 3 are very close to type 4 but: 1423 o Type 3 has only one slot, for the Home Address of the source. 1425 o When it can not add the source to the RH type 3 of an outbound 1426 packet, an intermediate MR: 1428 * MR MUST NOT send ICMP (RRH too small) 1429 * MUST NOT put the packet in a reverse tunnel 1431 Rather, it simply overwrites the source and forwards the packet up 1432 the tree as if the RRH had been properly updated. 1434 /* MR processing on outbound packet with RH type 3 support */ 1435 { 1437 if no RH type 3 or 4 in outer header /* First Mobile Router specific */ 1438 or RH type 4 present but saturated { /* Need a nested encapsulation */ 1440 if RRH is saturated { 1441 do ICMP back (RRH too small) 1442 } 1444 /* put packet in sliding reverse tunnel */ 1445 insert new IP header plus RRH 1446 set source address to the MR Home Address 1447 set destination address to the MR Home Agent Address 1448 add an RRH with all slots zeroed out 1449 compute IPsec AH on the resulting packet 1450 } 1452 /* All MRs including first */ 1453 if packet size > MTU { 1454 do ICMP back (Packet too Big) 1455 } else if RRH { 1456 select first free slot in RRH bottom up 1457 set it to source address from IP header 1458 overwrite source address in IP header with MR CareOf 1459 transmit packet 1460 } else if RH type 3 { 1461 if slot 0 is still free { 1462 /* this is end-to-end optimization */ 1463 set it to source address from IP header 1464 } 1465 overwrite source address in IP header with MR CareOf 1466 transmit packet 1467 } 1468 } 1470 o Since the path information is not available, the correspondent 1471 MUST NOT update its BCE based on the RH type 3. The CN (or HA) 1472 identifies the source from the entry in slot 0 and may reconstruct 1473 the initial packet using the CareOf in slot 1 as source for AH 1474 purposes. 1476 A.3.1 Routing Header Type 3 (HAddr option replacement) 1478 This is an RH-based alternative to the Home Address destination 1479 option. Its usage is described in Appendix A.3. 1481 The Type 3 Routing Header has the following format: 1483 0 1 2 3 1484 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 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Next Header | Hdr Ext Len | Routing Type=3| Segments Used | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | Reserved | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | | 1491 + + 1492 | | 1493 + Home Address + 1494 | | 1495 + + 1496 | | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 Next Header 1501 8-bit selector. Identifies the type of header immediately 1502 following the Routing header. Uses the same values as the IPv4 1503 Protocol field [13]. 1505 Hdr Ext Len 1507 8-bit unsigned integer. Length of the Routing header in 8-octet 1508 units, not including the first 8 octets. For the Type 3 Routing 1509 header, Hdr Ext Len is always 2. 1511 Routing Type 1513 8-bit unsigned integer. Set to 3. 1515 Segment Used 1517 8-bit unsigned integer. Number of slots used. Either 0 or 1. 1518 When the field is zero, then there is no MR on the path and it is 1519 valid for a CN that does not support RRH to ignore this header. 1521 Reserved 1523 32-bit reserved field. Initialized to zero for transmission; 1524 ignored on reception. 1526 Home Address 1528 128-bit home address of the source of the packet. 1530 The decision to sent RH type 3 or type 4 is up to the source of the 1531 RRH. Several algorithms may apply, one out of N being the simplest. 1533 IPsec HA processing is done as described in Section 11.1 for Type 4. 1535 Appendix B. Multi Homing 1537 B.1 Multi-Homed Mobile Network 1539 Consider difference between situation A and B in this diagram: 1541 ===?== ==?=== 1542 MR1 MR2 1543 | | 1544 ==?=====?== ==?====== situation A 1545 MR3 MR4 MR5 1546 | | | 1547 === === === 1549 ===?== ==?=== 1550 MR1 MR2 1551 | | 1552 ==?=====?=======?====== situation B 1553 MR3 MR4 MR5 1554 | | | 1555 === === === 1557 Going from A to B, MR5 may now choose between MR1 and MR2 for its 1558 Access (default) Router. In terms of Tree Information, MR5, as well 1559 as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once MR5 1560 selects its AR, MR2, say, MR5 belongs to the associated tree and 1561 whether MR1 can be reached or not makes no difference. 1563 As long as each MR has a single default router for all its outbound 1564 traffic, 2 different logical trees can be mapped over the physical 1565 configurations in both situations, and once the trees are 1566 established, both cases are equivalent for the processing of RRH. 1568 Note that MR5 MUST use a CareOf based on a prefix owned by its AR as 1569 source of the reverse tunnel, even if other prefixes are present on 1570 the Nemo, to ensure that a RH type 2 can be securely routed back. 1572 B.2 Multihomed Mobile Router 1574 Consider the difference between situation B and C in this diagram: 1576 ===?== ==?=== 1577 MR1 MR2 1578 | | 1579 ==?=====?=======?====== situation B 1580 MR3 MR4 MR5 1581 | | | 1582 === === === 1584 ==? ?== 1585 MR1 1586 | 1587 ==?=====?=======?====== situation C 1588 MR3 MR4 MR5 1589 | | | 1590 === === === 1592 In situation C, MR2's egress interface and its properties are 1593 migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home 1594 Agents, and 2 active interfaces. 1596 If MR1 uses both CareOf addresses at a given point of time, and if 1597 they belong to different prefixes to be used via different access 1598 routers, then MR1 actually belongs to 2 trees. It must perform some 1599 routing logic to decide whether to forward packets on either egress 1600 interface. Also, it MUST advertise both tree information sets in its 1601 RA messages. 1603 The difference between situations C and B is that when an attached 1604 router (MR5, say) selects a tree and forwards egress packets via MR1, 1605 it can not be sure that MR1 will actually forward the packets over 1606 that tree. If MR5 has selected a given tree for a specific reason, 1607 then a new source route header is needed to enforce that path on MR1. 1609 The other way around, MR5 may leave the decision up to MR1. If MR1 1610 uses the same access router for a given flow or at least a given 1611 destination, then the destination receives consistent RRHs. 1612 Otherwise, the BCE cache will flap, but as both paths are valid, the 1613 traffic still makes it through. 1615 The RRH seems compatible with the various cases of multi-homing 1616 exposed here, though in some cases, some additional work is needed. 1618 Full Copyright Statement 1620 Copyright (C) The Internet Society (2002). All Rights Reserved. 1622 This document and translations of it may be copied and furnished to 1623 others, and derivative works that comment on or otherwise explain it 1624 or assist in its implementation may be prepared, copied, published 1625 and distributed, in whole or in part, without restriction of any 1626 kind, provided that the above copyright notice and this paragraph are 1627 included on all such copies and derivative works. However, this 1628 document itself may not be modified in any way, such as by removing 1629 the copyright notice or references to the Internet Society or other 1630 Internet organizations, except as needed for the purpose of 1631 developing Internet standards in which case the procedures for 1632 copyrights defined in the Internet Standards process must be 1633 followed, or as required to translate it into languages other than 1634 English. 1636 The limited permissions granted above are perpetual and will not be 1637 revoked by the Internet Society or its successors or assigns. 1639 This document and the information contained herein is provided on an 1640 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1641 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1642 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1643 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1644 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1646 Acknowledgement 1648 Funding for the RFC Editor function is currently provided by the 1649 Internet Society.