idnits 2.17.00 (12 Aug 2021) /tmp/idnits3048/draft-thubert-nemo-reverse-routing-header-04.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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 644: '...e RH type 0, and the RH type 0 MUST be...' RFC 2119 keyword, line 688: '...tes the RRH. The Proposed Size MUST be...' RFC 2119 keyword, line 689: '...current size and MUST NOT be larger th...' RFC 2119 keyword, line 698: '...stination and it MUST NOT forward it t...' RFC 2119 keyword, line 701: '...o more space in the RRH SHOULD send an...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1331 has weird spacing: '...gnature would...' -- 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 (February 2004) is 6670 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 588, but not defined == Unused Reference: '4' is defined on line 1359, but no explicit reference was found in the text == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (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: 13 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Thubert 2 Internet-Draft M. Molteni 3 Expires: ao“t 1, 2004 Cisco Systems 4 February 2004 6 IPv6 Reverse Routing Header and its application to Mobile Networks 7 draft-thubert-nemo-reverse-routing-header-04 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on ao“t 1, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 Already existing proposals enable Mobile Networks by extending Mobile 38 IP to support Mobile Routers. In order to enable nested Mobile 39 Networks, some involve the overhead of nested tunnels between the 40 Mobile Routers and their Home Agents. 42 This proposal allows the building of a nested Mobile Network avoiding 43 the nested tunnel overhead. This is accomplished by using a new 44 routing header, called the reverse routing header, and by overlaying 45 a layer 3 tree topology on the evolving Mobile Network. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1 Recursive complexity . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology and Assumptions . . . . . . . . . . . . . . . 5 52 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 54 3. An Example . . . . . . . . . . . . . . . . . . . . . . . . 7 55 4. New Routing Headers . . . . . . . . . . . . . . . . . . . 11 56 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . 11 57 4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . 13 58 4.3 Extension Header order . . . . . . . . . . . . . . . . . . 15 59 5. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 60 6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . 19 61 6.1 Modified Router Advertisement Message Format . . . . . . . 19 62 6.2 New Tree Information Option Format . . . . . . . . . . . . 20 63 7. Binding Cache Management . . . . . . . . . . . . . . . . . 23 64 7.1 Binding Updates . . . . . . . . . . . . . . . . . . . . . 23 65 7.2 RRH Heartbeat . . . . . . . . . . . . . . . . . . . . . . 23 66 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . 24 67 9. Mobile Router Operation . . . . . . . . . . . . . . . . . 26 68 9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 26 69 9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 27 70 9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 27 71 9.4 Processing of Tree Information Option . . . . . . . . . . 28 72 9.5 Processing of the extended Routing Header Type 2 . . . . . 28 73 9.6 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 30 74 10. Mobile Host Operation . . . . . . . . . . . . . . . . . . 30 75 11. Security Considerations . . . . . . . . . . . . . . . . . 30 76 11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . . 30 77 11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . . . . 31 78 11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . . . . 31 79 11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . . 32 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 33 81 References . . . . . . . . . . . . . . . . . . . . . . . . 34 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 35 83 A. Optimizations . . . . . . . . . . . . . . . . . . . . . . 36 84 A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 36 85 A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 37 86 A.2.1 Routing Header Type 3 (Home Address option replacement) . 38 87 B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . 40 88 B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 40 89 B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 41 90 C. Changes from Previous Version of the Draft . . . . . . . . 42 91 Intellectual Property and Copyright Statements . . . . . . 43 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 Mobile Network may be either simple (a network with one 99 mobile router) or nested, single or multi-homed. This proposal starts 100 from the assumption that nested Mobile Networks will be the norm, and 101 so presents a solution that avoids the tunnel within tunnel overhead 102 of already 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 (LSRR) 112 [6] adapted for IPv6. RRH records the route out of the nested Mobile 113 Network and can be trivially converted into a routing header for 114 packets destined to the Mobile Network. 116 This version focuses on single-homed Mobile Networks. Hints for 117 further 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 Mobile IPv6 [1]. Specifically the CN can also be 121 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 Recursive complexity 130 A number of drafts and publications suggest -or can be extended to- a 131 model where the Home Agent and any arbitrary Correspondent would 132 actually get individual binding from the chain of nested Mobile 133 Routers, and form a routing header appropriately. 135 An intermediate MR would keep track of all the pending communications 136 between hosts in its subtree of Mobile Networks and their CNs, and a 137 binding message to each CN each time it changes its point of 138 attachment. 140 If this was done, then each CN, by receiving all the binding messages 141 and processing them recursively, could infer a partial topology of 142 the nested Mobile Network, sufficient to build a multi-hop routing 143 header for packets sent to nodes inside the nested Mobile Network. 145 However, this extension has a cost: 147 1. Binding Update storm 149 when one MR changes its point of attachment, it needs to send a 150 BU to all the CNs of each node behind him. When the Mobile 151 Network is nested, the number of nodes and relative CNs can be 152 huge, leading to congestions and drops. 154 2. Protocol Hacks 156 Also, in order to send the BUs, the MR has to keep track of all 157 the traffic it forwards to maintain his list of CNs. In case of 158 IPSec tunneled traffic, that CN information may not be available. 160 3. CN operation 162 The computation burden of the CN becomes heavy, because it has to 163 analyze each BU in a recursive fashion in order to infer nested 164 Mobile Network topology required to build a multi hop routing 165 header. 167 4. Missing BU 169 If a CN doesn't receive the full set of PSBU sent by the MR, it 170 will not be able to infer the full path to a node inside the 171 nested Mobile Network. The RH will be incomplete and the packet 172 may or may not be delivered. 174 5. Obsolete BU 176 If the Binding messages are sent asynchronously by each MR, then, 177 when the relative position of MRs and/or the TLMR point of 178 attachment change rapidly, the image of Mobile Network that the 179 CN maintains is highly unstable. If only one BU in the chain is 180 obsolete due to the movement of an intermediate MR, the 181 connectivity may be lost. 183 A conclusion is that the path information must be somehow aggregated 184 to provide the CN with consistent snapshots of the full path across 185 the Mobile Network. This can be achieved by an IPv6 form of loose 186 source / record route header, that we introduce here as a Reverse 187 Routing Header 189 2. Terminology and Assumptions 191 2.1 Terminology 193 Simple Mobile Network 195 One or more IP subnets attached to a MR and mobile as a unit, with 196 respect to the rest of the Internet. A simple Mobile Network can 197 be either single or multi-homed. 199 The IP subnets may have any kind of topology and may contain fixed 200 routers. All the access points of the Mobile Network (to which 201 further MRs may attach) are on the same layer 2 link of the MR. 203 We like to represent a simple single-homed Mobile Network as an 204 hanger, because it has only one uplink hook and a bar to which 205 multiple hooks can be attached. Graphically we use the question 206 mark "?" to show the uplink hook (interface) connected to the MR, 207 and the "=" sign to represent the bar: 209 ? 210 MR1 211 | 212 =============== 214 Nested Mobile Network 216 A group of simple Mobile Networks recursively attached together 217 and implementing nested Mobility as defined in [2]. 219 ? 220 MR1 221 | 222 ====?===============?==== 223 MR2 MR3 224 | | 225 =========== ===?==========?=== 226 MR4 MR5 227 | | 228 ========== ============ 230 IPv6 Mobile Host 232 A IPv6 Host, with support for MIPv6 MN, and the additional Nemo 233 capability described in this draft. 235 Home prefix 237 Network prefix, which identifies the home link within the Internet 238 topology. 240 Mobile Network prefix 242 Network prefix, common to all IP addresses in the Mobile Network 243 when the MR is attached to the home link. It may or may not be a 244 subset of the Home subnet prefix. 246 Inbound direction: 248 direction from outside the Mobile Network to inside 250 Outbound direction: 252 direction from inside the Mobile Network to outside 254 2.2 Assumptions 256 We make the following assumptions: 258 1. A MR has one Home Agent and one Home Address -> one primary CoA. 260 2. A MR attaches to a single Attachment Router as default router. 262 3. A MR may have more than one uplink interface. 264 4. An interface can be either wired or wireless. The text assumes 265 that interfaces are wireless for generality. 267 5. Each simple Mobile Network may have more that one L2 Access 268 Point, all of them controlled by the same Attachment Router, 269 which we assume to be the Mobile Router. 271 Since an MR has only one primary CoA, only one uplink interface can 272 be used at a given point of time. Since the MR attaches to a single 273 attachment router, if due care is applied to avoid loops, then the 274 resulting topology is a tree. 276 3. An Example 278 The nested Mobile Network in the following figure has a tree 279 topology, according to the assumptions in Section 2.2. In the tree 280 each node is a simple Mobile Network, represented by its MR. 282 +---------------------+ 283 | Internet |---CN 284 +---------------|-----+ 285 / Access Router 286 MR3_HA | 287 ======?====== 288 MR1 289 | 290 ====?=============?==============?=== 291 MR5 MR2 MR6 292 | | | 293 =========== ===?========= ============= 294 MR3 295 | 296 ==|=========?== <-- Mobile Network3 297 LFN1 MR4 298 | 299 ========= 301 An example nested Mobile Network 303 This example focuses on a Mobile Network node at depth 3 (Mobile 304 Network3) inside the tree, represented by its mobile router MR3. The 305 path to the Top Level Mobile Router (TLMR) MR1 and then the Internet 306 is 308 MR3 -> MR2 -> MR1 -> Internet 310 Consider the case where a LFN belonging to Mobile Network3 sends a 311 packet to a CN in the Internet, and the CN replies back. With the 312 tunnel within tunnel approach described by [3], we would have three 313 bi-directional nested tunnels: 315 -----------. 316 --------/ /-----------. 317 -------/ | | /----------- 318 CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN 319 MR3_HA -------\ | | \----------- MR3 320 MR2_HA --------\ \----------- MR2 321 MR1_HA ----------- MR1 323 Depending on the relative location of MR1_HA, MR2_HA and MR3_HA, this 324 may lead to a very inefficient "pinball" routing in the 325 Infrastructure. 327 On the other hand, with the RRH approach we would have only one 328 bi-directional tunnel: 330 --------------------------------- MR1 ---- MR2 ---- MR3 331 CN ------( - - - - - - - - - - - - - - - - (-------- LFN 332 MR3_HA --------------------------------- MR1 ---- MR2 ---- MR3 334 The first mobile router on the path, MR3, in addition to tunneling 335 the packet to its HA, adds a reverse routing header with N = 3 336 pre-allocated slots. Choosing the right value for N is discussed in 337 Section 6.2. The bottom slot is equivalent to the MIPv6 Home Address 338 option. MR3 inserts its home address MR3_HoA into slot 0. 340 The outer packet has source MR3's Care of Address, MR3_CoA, and 341 destination MR3's Home Agent, MR3_HA: 343 <-------------- outer IPv6 header --------------------> 344 +-------+-------++ -- ++----+-------+-------+---------+ +------- 345 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 346 |MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET 347 | | |: :| 4 | | | | | 348 +-------+-------++ -- ++----+-------+-------+---------+ +------- 350 The second router on the path, MR2, notices that the packet already 351 contains an RRH, and so it overwrites the source address of the 352 packet with its own address, MR2_CoA, putting the old source address, 353 MR3_CoA, in the first free slot of the RRH. 355 The outer packet now has source MR2_CoA and destination MR3_HA; the 356 RRH from top to bottom is MR3_CoA | MR3_HoA: 358 <-------------- outer IPv6 header --------------------> 359 +-------+-------++ -- ++----+-------+-------+---------+ +------- 360 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 361 |MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA|MR3_HoA | |iPACKET 362 | | |: :| 4 | | | | | 363 +-------+-------++ -- ++----+-------+-------+---------+ +------- 364 In general the process followed by the second router is repeated by 365 all the routers on the path, including the TLMR (in this example 366 MR1). When the packet leaves MR1 the source address is MR1_CoA and 367 the RRH is MR2_CoA | MR3_CoA | MR3_HoA: 369 <-------------- outer IPv6 header --------------------> 370 +-------+-------++ -- ++----+-------+-------+---------+ +------- 371 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 372 |MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET 373 | | |: :| 4 | | | | | 374 +-------+-------++ -- ++----+-------+-------+---------+ +------- 376 In a colloquial way we may say that while the packet travels from MR3 377 to MR3_HA, the Mobile Network tunnel end point "telescopes" from MR3 378 to MR2 to MR1. 380 When the home agent MR3_HA receives the packet it notices that it 381 contains a RRH and it looks at the bottom entry, MR3_HoA. This entry 382 is used as if it were a MIPv6 Home Address destination option, i.e. 383 as an index into the Binding Cache. When decapsulating the inner 384 packet the home agent performs the checks described in Section 8, and 385 if successful it forwards the inner packet to CN. 387 MR3_HA stores two items in the Bind Cache Entry associated with MR3: 388 the address entries from RRH, to be used to build the RH, and the 389 packet source address MR1_CoA, to be used as the first hop. 391 Further packets from the CN to the LFN are plain IPv6 packets. 392 Destination is LFN, and so the packet reaches MR3's home network. 394 MR3_HA intercepts it, does a Bind Cache prefix lookup and obtains as 395 match the MR3 entry, containing the first hop and the information 396 required to build the RH. It then puts the packet in the tunnel 397 MR3_HA -- MR3 as follows: source address MR3_HA and destination 398 address the first hop, MR1_CoA. The RH is trivially built out of the 399 previous RRH: MR2_CoA | MR3_CoA | MR3_HoA: 401 <-------------- outer IPv6 header --------------------> 402 +-------+-------++ -- ++----+-------+-------+---------+ +------- 403 |oSRC |oDST |: :|oRH | | | | | 404 |MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET 405 | | |: :| 2 | | | | | 406 +-------+-------++ -- ++----+-------+-------+---------+ +------- 407 The packet is routed with plain IP routing up to the first 408 destination MR1_CoA. 410 The RH of the outer packet is type 2 as in MIPv6 [1], but has 411 additional semantics inherited from type 0: it contains the path 412 information to traverse the nested Mobile Network from the TLMR to 413 the tunnel endpoint MR3. Each intermediate destination forwards the 414 packet to the following destination in the routing header. The 415 security aspects of this are treated in Section 11.2. 417 MR1, which is the initial destination in the IP header, looks at the 418 RH and processes it according to Section 9, updating the RH and the 419 destination and sending it to MR2_CoA. MR2 does the same and so on 420 until the packet reaches the tunnel endpoint, MR3. 422 When the packet reaches MR3, the source address in the IP header is 423 MR3_HA, the destination is MR3_CoA and in the RH there is one segment 424 left, MR3_HoA. As a consequence the packet belongs to the MR3_HA -- 425 MR3 tunnel. MR3 decapsulates the inner packet, applying the rules 426 described in Section 9 and sends it to LFN. The packet that reaches 427 LFN is the plain IPv6 packet that was sent by CN. 429 4. New Routing Headers 431 This draft modifies the MIPv6 Routing Header type 2 and introduces 432 two new Routing Headers, type 3 and 4. Type 3, which is an 433 optimization of type 4 will be discussed in Appendix A.2.1. The draft 434 presents their operation in the context of Mobile Routers although 435 the formats are not tied to Mobile IP and could be used in other 436 situations. 438 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) 440 Mobile IPv6 uses a Routing header to carry the Home Address for 441 packets sent from a Correspondent Node to a Mobile Node. In [1], this 442 Routing header (Type 2) is restricted to carry only one IPv6 address. 443 The format proposed here extends the Routing Header type 2 to be 444 multi-hop. 446 The processing of the multi-hop RH type 2 inherits from the RH type 0 447 described in IPv6 [10]. Specifically: the restriction on multicast 448 addresses is the same; a RH type 2 is not examined or processed until 449 it reaches the node identified in the Destination Address field of 450 the IPv6 header; in that node, the RH type 0 algorithm applies, with 451 added security checks. 453 The construction of the multi-hop RH type 2 by the HA is described in 454 Section 8; the processing by the MRs is described in Section 9.5; and 455 the security aspects are treated in Section 11.2. 457 The destination node of a packet containing a RH type 2 can be a MR 458 or some other kind of node. If it is a MR it will perform the 459 algorithm described in Section 9.5, otherwise it will operate as 460 prescribed by IPv6 [10] when the routing type is unrecognized. 462 The multi-hop Routing Header type 2, as extended by this draft, has 463 the following format: 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Next Header | Hdr Ext Len | Routing Type=2| Segments Left | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Reserved | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | | 473 + + 474 | | 475 + Address[1] + 476 | | 477 + + 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 + + 482 | | 483 + Address[2] + 484 | | 485 + + 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 . . . 489 . . . 490 . . . 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | | 493 + + 494 | | 495 + Address[n] + 496 | | 497 + + 498 | | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Next Header 503 8-bit selector. Identifies the type of header immediately 504 following the Routing header. Uses the same values as the IPv4 505 Protocol field [13]. 507 Hdr Ext Len 509 8-bit unsigned integer. Length of the Routing header in 8-octet 510 units, not including the first 8 octets. For the Type 2 Routing 511 header, Hdr Ext Len is equal to two times the number of addresses 512 in the header. 514 Routing Type 516 8-bit unsigned integer. Set to 2. 518 Segments Left 520 8-bit unsigned integer. Number of route segments remaining, i.e., 521 number of explicitly listed intermediate nodes still to be visited 522 before reaching the final destination. 524 Reserved 526 32-bit reserved field. Initialized to zero for transmission; 527 ignored on reception. 529 Address[1..n] 531 Vector of 128-bit addresses, numbered 1 to n. 533 4.2 Routing Header Type 4 (The Reverse Routing Header) 535 The Routing Header type 4, or Reverse Routing Header (RRH), is a 536 variant of IPv4 loose source and record route (LSRR) [6] adapted for 537 IPv6. 539 Addresses are added from bottom to top (0 to n-1 in the picture). The 540 RRH is designed to help the destination build an RH for the return 541 path. 543 When a RRH is present in a packet, the rule for upper-layer checksum 544 computing is that the source address used in the pseudo-header is 545 that of the original source, located in the slot 0 of the RRH, unless 546 the RRH slot 0 is empty, in which case the source in the IP header of 547 the packet is used. 549 As the 'segment left' field of the generic RH is reassigned to the 550 number of segments used, an IPv6 node that does not support RRH will 551 discard the packet, unless the RRH is empty. 553 The RRH contains n pre-allocated address slots, to be filled by each 554 MR in the path. It is possible to optimize the number of slots using 555 the Tree Information Option described in Section 6.2. 557 The Type 4 Routing Header has the following format: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Next Header | Hdr Ext Len | Routing Type=4| Segments Used | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Sequence Number | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | | 567 + + 568 | | 569 + Slot[n-1] + 570 | | 571 + + 572 | | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 . . . 575 . . . 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 + + 579 | | 580 + Slot[1] (1st MR CoA) + 581 | | 582 + + 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | | 586 + + 587 | | 588 + Slot[0] (Home address) + 589 | | 590 + + 591 | | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Next Header 596 8-bit selector. Identifies the type of header immediately 597 following the Routing header. Uses the same values as the IPv4 598 Protocol field [13]. 600 Hdr Ext Len 602 8-bit unsigned integer. Length of the Routing header in 8-octet 603 units, not including the first 8 octets. For the Type 4 Routing 604 header, Hdr Ext Len is equal to two times the number of addresses 605 in the header. 607 Routing Type 609 8-bit unsigned integer. Set to 4. 611 Segments Used 613 8-bit unsigned integer. Number of slots used. Initially set to 1 614 by the MR when only the Home Address is there. Incremented by the 615 MRs on the way as they add the packets source addresses to the 616 RRH. 618 Sequence Number 620 32-bit unsigned integer. The Sequence Number starts at 0, and is 621 incremented by the source upon each individual packet. Using the 622 Radia Perlman's lollipop algorithm, values between 0 and 255 are 623 'negative', left to indicate a reboot or the loss of HA 624 connectivity, and are skipped when wrapping and upon positive 625 Binding Ack. The sequence number is used to check the freshness of 626 the RRH; anti-replay protection is left to IPsec AH. 628 Slot[n-1..0] 630 Vector of 128-bit addresses, numbered n-1 to 0. 632 When applied to the Nemo problem, the RRH can be used to update the 633 HA on the actual location of the MR. Only MRs forwarding packets on 634 an egress interface while not at home update it on the fly. 636 A RRH is inserted by the first MR on the Mobile Network outbound 637 path, as part of the reverse tunnel encapsulation; it is removed by 638 the associated HA when the tunneled packet is decapsulated. 640 4.3 Extension Header order 642 The RH type 2 is to be placed as any RH as described in [10] section 643 4.1. If a RH type 0 is present in the packet, then the RH type 2 is 644 placed immediately after the RH type 0, and the RH type 0 MUST be 645 consumed before the RH type 2. 647 RH type 3 and 4 are mutually exclusive. They are to be placed right 648 after the Hop-by-Hop Options header if any, or else right after the 649 IPv6 header. 651 As a result, the order prescribed in section 4.1 of RFC 2460 becomes: 653 IPv6 header 655 Hop-by-Hop Options header 657 Routing header type 3 or 4 659 Destination Options header (note 1) 661 Routing header type 0 663 Routing header type 2 665 Fragment header 667 Authentication header (note 2) 669 Encapsulating Security Payload header (note 2) 671 Destination Options header (note 3) 673 upper-layer header 675 5. ICMP 677 The RRH could have fewer slots than the number of MRs in the path 678 because either the nested Mobile Network topology is changing too 679 quickly or the MR that inserted the RRH could have a wrong 680 representation of the topology. 682 To solve this problem a new ICMP message is introduced, "RRH 683 Warning", type 64. Note that this ICMP message creates a new class of 684 warning messages besides the error messages and the control messages 685 of ICMP. 687 This message allows a MR on the path to propose a larger number of 688 slots to the MR that creates the RRH. The Proposed Size MUST be 689 larger than the current size and MUST NOT be larger than 8. 691 The originating MR must rate-limit the ICMP messages to avoid 692 excessive ICMP traffic in the case of the source failing to operate 693 as requested. 695 The originating MR must insert an RH type 2 based on the RRH in the 696 associated IP header, in order to route the ICMP message back to the 697 source of the reverse tunnel. A MR that receives this ICMP message is 698 the actual destination and it MUST NOT forward it to the (LFN) source 699 of the tunneled packet. 701 A MR on the path that finds no more space in the RRH SHOULD send an 702 ICMP "RRH warning" back to the MR that inserted the RRH. On the other 703 hand, a MR should always be able, by receiving TI option with up to 704 date tree depth (see Section Section 6.2). to correctly size the RRH 705 to insert in an outgoing packet. 707 The type 64 ICMP has the following format: 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Type = 64 | Code = 0 | Checksum | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Current Size | Proposed Size | Reserved | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | As much of invoking packet | 717 + as will fit without the ICMPv6 packet + 718 | exceeding the minimum IPv6 MTU | 719 . . 720 . . 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Type 725 64 [To Be Assigned] 727 Code 0: RRH too small 729 The originating MR requires the source to set the RRH size to a 730 larger value. The packet that triggered the ICMP will still be 731 forwarded by the MR, but the path cannot be totally optimized (see 732 Section 9.3). 734 Checksum 736 The ICMP checksum [12]. 738 Current Size 740 RRH size of the invoking packet, as a reference. 742 Proposed Size 744 The new value, expressed as a number of IPv6 addresses that can 745 fit in the RRH. 747 Reserved 749 16-bit reserved field. Initialized to zero for transmission; 750 ignored on reception. 752 6. Modifications to IPv6 Neighbor Discovery 754 6.1 Modified Router Advertisement Message Format 756 Mobile IPv6 [1] modifies the format of the Router Advertisement 757 message [11] by the addition of a single flag bit (H) to indicate 758 that the router sending the Advertisement message is serving as a 759 home agent on this link. 761 This draft adds another single flag bit (N) to indicate that the 762 router sending the advertisement message is a MR. This means that the 763 link on which the message is sent is a Mobile Network, which may or 764 may not be at home. 766 The Router Advertisement message has the following format: 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Type | Code | Checksum | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Reachable Time | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Retrans Timer | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Options ... 780 +-+-+-+-+-+-+-+-+-+-+-+- 782 This format represents the following changes over that originally 783 specified for Neighbor Discovery [11]: 785 Home Agent (H) 787 The Home Agent (H) bit is set in a Router Advertisement to 788 indicate that the router sending this Router Advertisement is also 789 functioning as a Mobile IP home agent on this link. 791 NEMO Capable (N) 793 The NEMO Capable (N) bit is set in a Router Advertisement to 794 indicate that the router sending this Router Advertisement is also 795 functioning as a Mobile Router on this link, so that the link is a 796 Mobile Network, possibly away from home. 798 6.2 New Tree Information Option Format 800 This draft defines a new Tree Information option, used in Router 801 Advertisement messages. Fields set by the TLMR are propagated 802 transparently by the MRs. Mobile Routers SHOULD add that option to 803 the Router Advertisement messages sent over the ingress interfaces. 805 The Tree Information option has the following format: 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Type | Length = 6 | TreePreference| TreeDepth | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 |F|H| Reserved | Bandwidth | DelayTime | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | MRPreference | BootTimeRandom | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | PathCRC | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | | 819 + + 820 | | 821 + Tree TLMR Identifier + 822 | | 823 + + 824 | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | | 827 + + 828 | | 829 + Tree Group + 830 | | 831 + + 832 | | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 Type 837 8-bit unsigned integer set to 10 by the TLMR. 839 Length 841 8-bit unsigned integer set to 6 by the TLMR. The length of the 842 option (including the type and length fields) in units of 8 843 octets. 845 TreePreference 847 8-bit unsigned integer set by the TLMR to its configured 848 preference. Range from 0 = lowest to 255 = highest. 850 TreeDepth 852 8-bit unsigned integer set to 0 by the TLMR and incremented by 1 853 by each MR down the tree. 855 Grounded (G) 857 1-bit flag. Set by the TLMR to indicate that it is either attached 858 to a fixed network or at home. 860 Home Agent (H) 862 1-bit flag. Set by the TLMR to indicate that it is also 863 functioning as a Home Agent, for re-homing purposes. 865 Reserved 867 6-bit unsigned integer, set to 0 by the TLMR. 869 Bandwidth 871 8-bit unsigned integer set by the TLMR and decremented by MRs with 872 lower egress bandwidth. This is a power of 2 so that the available 873 egress bandwidth in bps is between 2^Bandwidth and 874 2^(Bandwidth+1). 0 means 'unspecified' and can not be modified 875 down the tree. 877 DelayTime 879 16-bit unsigned integer set by the TLMR. Tree time constant in 880 milliseconds. 882 MRPreference 884 8-bit signed integer. Set by each MR to its configured preference. 885 Range from 0 = lowest to 255 = highest. 887 BootTimeRandom 889 24-bit unsigned integer set by each MR to a random value that the 890 MR generates at boot time. 892 PathCRC 894 32-bit unsigned integer CRC, updated by each MR. This is the 895 result of a CRC-32c computation on a bit string obtained by 896 appending the received value and the MR CareOf Address. TLMRs use 897 a 'previous value' of zeroes to initially set the pathCRC. 899 Tree TLMR Identifier 901 IPv6 global address, set by the TLMR. Identifier of the tree. 903 Tree Group 905 IPv6 global address, set by the TLMR. Identifier of the tree 906 group. A MR may use the Tree Group in its tree selection 907 algorithm. 909 The TLMR MUST include this option in its Router Advertisements. 911 A MR receiving this option from its Attachment Router MUST update the 912 TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST 913 propagate it on its ingress interface(s), as described in Section 914 9.4. 916 The alignment requirement of the Tree Information option is 8n. 918 7. Binding Cache Management 920 7.1 Binding Updates 922 A MIPv6 or NEmo Binding Update provides more information than just 923 the path in the nested cloud so they are still used as described in 924 MIPv6 [1] for Home Registration and de-registration. The only 925 difference when using RRH is that the Home Address Destination Option 926 and the alternate CareOf MIP option MUST be omitted. 928 7.2 RRH Heartbeat 930 Intermediate updates (or just refreshes) between BUs are obtained as 931 one of the results of processing the RRH by the HA. 933 When the MR becomes aware of a topology change in the tree (for 934 examples it changes point of attachment, it obtains a new CoA, it 935 receives a Tree Information Option in an RA message that indicates a 936 change in the attachment tree) or in the absence of traffic (detected 937 by a timeout) to the HA, it must send an RRH Heartbeat, which is a 938 binding update with a RRH. 940 8. Home Agent Operation 942 This section inherits from chapter 10 of MIPv6 [1], which is kept 943 unmodified except for parts 10.5 and 10.6 which are extended. This 944 draft mostly adds the opportunity for a MN to update the Binding 945 Cache of its Home Agent using RRH, though it does not change the fact 946 that MNs still need to select a home agent, register and deregister 947 to it, using the MIP Bind Update. 949 This draft extends [1] section 10.6 as follows: 951 o The entry point of the tunnel is now checked against the TLMR as 952 opposed to the primary CoA. 954 o The Binding Cache can be updated based on RRH with proper AH 955 authentication. 957 As further explained in Section 7.1, this specification modifies MIP 958 so that the HA can rely on the RH type 4 (RRH) to update its Bind 959 Cache Entry (BCE), when the Mobile Node moves. The conceptual content 960 of the BCE is extended to contain a sequence counter, and the 961 sequence of hops within the --potentially nested-- Mobile Network to 962 a given Mobile Node. The sequence counter is initially set to 0. 964 When the HA receives a packet destined to itself, it checks for the 965 presence of a Routing Header of type 3 or 4. Both contain as least 966 the entry for the home address of the MN in slot 0; this replaces the 967 MIP Home Address Option and allows the HA to determine the actual 968 source of the packet, to access the corresponding security 969 association. 971 As explained in Section 11.2, the HA MUST verify the authenticity of 972 the packet using IPSEC AH and drop packets that were not issued by 973 the proper Mobile Node. An RRH is considered only if the packet is 974 authenticated and if its sequence number is higher than the one saved 975 in the BCE. 977 Also, an RRH is considered only if an initial Bind Update exchange 978 has been successfully completed between the Mobile Node and its Home 979 Agent for Home Registration. If the RRH is valid, then the Bind Cache 980 Entry is revalidated for a lifetime as configured from the initial 981 Bind Update. 983 The BCE abstract data is updated as follows: 985 The first hop for the return path is the last hop on the path of 986 the incoming packet, that is between the HA and the Top Level 987 Mobile Router (TLMR) of the Mobile Network. The HA saves the IP 988 address of the TLMR from the source field in the IP header. 990 The rest of the path to the MN is found in the RRH. 992 The sequence counter semantics is changed as described in Section 993 4.2 995 This draft extends [1] section 10.5 as follows: 997 A Home Agent advertises the prefixes of its registered Mobile 998 Routers, during the registration period, on the local Interior 999 Gateway Protocol (IGP). 1001 The Routing Header type 2 is extended to be multi-hop. 1003 The Home Agent is extended to support routes to prefixes that are 1004 owned by Mobile Routers. This can be configured statically, or can be 1005 exchanged using a routing protocol as in [3], which is out of the 1006 scope of this document. As a consequence of this process, the Home 1007 Agent which is selected by a Mobile Router advertises reachability of 1008 the MR prefixes for the duration of the registration over the local 1009 IGP. 1011 When a HA gets a packet for which the destination is a node behind a 1012 Mobile Router, it places the packet in the tunnel to the associated 1013 MR. This ends up with a packet which destination address in the IP 1014 Header is the TLMR, and with a Routing Header of type 2 for the rest 1015 of the way to the Mobile Router, which may be multi-hop. 1017 To build the RH type 2 from the RRH, the HA sets the type to 2, and 1018 clears the bits 32-63 (byte 4 to 7). 1020 9. Mobile Router Operation 1022 This section inherits from chapter 11 of [1], which is extended to 1023 support Mobile Networks and Mobile Routers as a specific case of 1024 Mobile Node. 1026 This draft extends section 11.2.1 of MIPv6 [1] as follows: 1028 o When not at home, an MR uses a reverse tunnel with its HA for all 1029 the traffic that is sourced in its mobile network(s); traffic 1030 originated further down a nested network is not tunneled twice but 1031 for exception cases. 1033 o The full path to and within the Mobile Network is piggy-backed 1034 with the traffic on a per-packet basis to cope with rapid 1035 movement. This makes the packet construction different from MIPv6. 1037 The MR when not at home sets up a bi-directional tunnel with its HA. 1038 The reverse direction MR -> HA is needed to assure transparent 1039 topological correctness to LFNs, as in [3]. But, as opposed to that 1040 solution, nested tunnels are generally avoided. 1042 9.1 Processing of ICMP "RRH too small" 1044 The New ICMP message "RRH too Small" is presented in Section 5. This 1045 message is addressed to the MR which performs the tunnel 1046 encapsulation and generates the RRH. 1048 Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate 1049 it to the originating LFN or inner tunnel source, but MUST process it 1050 for itself. 1052 If the Current Size in the ICMP messages matches the actual current 1053 number of slots in RRH, and if the ICMP passes some safety checks as 1054 described in Section 5, then the MR MAY adapt the number of slots to 1055 the Proposed Size. 1057 9.2 Processing of ICMP error 1059 ICMP back { 1061 if RRH is present { 1062 compute RH type 2 based on RRH 1063 get packet source from IP header 1064 send ICMP error to source including RH type 2. 1065 } 1066 else { 1067 get packet source from IP header 1068 send ICMP error to source with no RH. 1069 } 1070 } 1072 When the MR receives an ICMP error message, it checks whether it is 1073 the final destination of the packet by looking at the included 1074 packet. If the included packet has an RRH, then the MR will use the 1075 RRH to forward the ICMP to the original source of the packet. 1077 9.3 Processing of RHH for Outbound Packets 1079 if no RRH in outer header /* First Mobile Router specific */ 1080 or RRH present but saturated { /* Need a nested encapsulation */ 1082 if RRH is saturated { 1083 do ICMP back (RRH too small) 1084 } 1086 /* put packet in sliding reverse tunnel */ 1087 insert new IP header plus RRH 1088 set source address to the MR Home Address 1089 set destination address to the MR Home Agent Address 1090 add an RRH with all slots zeroed out 1091 compute IPsec AH on the resulting packet 1092 } 1094 /* All MRs including first */ 1095 if packet size <= MTU { 1096 select first free slot in RRH bottom up 1097 set it to source address from IP header 1098 overwrite source address in IP header with MR CareOf 1099 transmit packet 1100 } else { 1101 do ICMP back (Packet too Big) 1102 } 1103 If the packet already contains an RRH in the outer header, and has a 1104 spare slot, the MR adds the source address from the packet IP header 1105 to the RRH and overwrites the source address in the IP header with 1106 its CoA. As a result, the packets are always topologically correct. 1108 Else, if the RRH is present but is saturated, and therefore the 1109 source IP can not be added, the MR sends a ICMP 'RRH too small' to 1110 the tunnel endpoint which originated the outer packet, using the RRH 1111 info to route it back. The ICMP message is a warning, and the packet 1112 is not discarded. Rather, the MR does a nested encapsulation of the 1113 packet in its own reverse tunnel home with an additional RRH. 1115 Else, if the packet does not have an RRH, the MR puts it in its 1116 reverse tunnel, sourced at the CoA, with an RRH indicating in slot 0 1117 the Home Address of the MR, and with proper IPsec AH as described 1118 further in Section 11.1. 1120 9.4 Processing of Tree Information Option 1122 The Tree Information option in Router Advertisement messages allows 1123 the Mobile Router to select a tree and learn about its capabilities. 1124 The treeDepth can be used to compute the optimum number of slots in 1125 the RRH. 1127 The RRH contains an entry for the home address in slot 0, and one for 1128 every CareOf on the way but that of the last Mobile Router (TLMR). As 1129 the TLMR sets the treeDepth to 0 and each MR increments it on the way 1130 down the tree, the optimum number of slots is normally (treeDepth+1), 1131 where treeDepth is the depth advertised by the MR over its Mobile 1132 Networks. 1134 9.5 Processing of the extended Routing Header Type 2 1136 if Segments Left = 0 { 1138 /* new check: packet must be looped back internally */ 1139 if packet doesn't come from a loopback interface { 1140 discard the packet 1141 return 1142 } 1144 proceed to process the next header in the packet, whose type is 1145 identified by the Next Header field in the Routing header 1146 } 1147 else if Hdr Ext Len is odd { 1148 send an ICMP Parameter Problem, Code 0, message to the Source 1149 Address, pointing to the Hdr Ext Len field, and discard the 1150 packet 1152 } 1153 else { 1154 compute n, the number of addresses in the Routing header, by 1155 dividing Hdr Ext Len by 2 1157 if Segments Left is greater than n { 1158 send an ICMP Parameter Problem, Code 0, message to the Source 1159 Address, pointing to the Segments Left field, and discard the 1160 packet 1161 } 1162 else { 1163 decrement Segments Left by 1; 1165 compute i, the index of the next address to be visited in 1166 the address vector, by subtracting Segments Left from n 1168 if Address [i] or the IPv6 Destination Address is multicast { 1169 discard the packet 1170 } 1171 else { 1172 /* new security check */ 1173 if Address [i] doesn't belong to one of the Mobile Network prefixes { 1174 discard the packet 1175 return 1176 } 1178 /* new check: keep MIPv6 behavior: prevent packets from being 1179 * forwarded outside the node. 1180 */ 1181 if Segments Left equals 0 and Address[i] isn't the node's own 1182 home address { 1183 discard the packet 1184 return 1185 } 1186 swap the IPv6 Destination Address and Address[i] 1187 if the IPv6 Hop Limit is less than or equal to 1 { 1188 send an ICMP Time Exceeded -- Hop Limit Exceeded in 1189 Transit message to the Source Address and discard the 1190 packet 1191 } 1192 else { 1193 decrement the Hop Limit by 1 1194 resubmit the packet to the IPv6 module for transmission 1195 to the new destination; 1196 } 1197 } 1198 } 1199 } 1201 9.6 Decapsulation 1203 A MR when decapsulating a packet from its HA must perform the 1204 following checks 1206 1. Destination address 1208 The destination address of the inner packet must belong to one of 1209 the Mobile Network prefixes. 1211 10. Mobile Host Operation 1213 When it is at Home, a Mobile Host issues packets with source set to 1214 its home address and with destination set to its CN, in a plain IPv6 1215 format. 1217 When a MH is not at home but is attached to a foreign link in the 1218 Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to 1219 manage its mobility. 1221 When a MH is visiting a foreign Mobile Network, it forwards its 1222 outbound packets over the reverse tunnel (including RRH) to its HA. 1223 One can view that operation as a first MR process applied on a plain 1224 IPv6 packet issued by a LFN. 1226 As a result, the encapsulating header include: 1228 with source set to the MH COA and destination set to the MH HA 1230 with slot 0 set to the MH Home Address 1232 The inner packet is the plain IPv6 packet from the MH Home Address to 1233 the CN. 1235 11. Security Considerations 1237 This section is not complete; further work is needed to analyse and 1238 solve the security problems of record and source route. 1240 Compared to MIPv6, the main security problem seems to be the fact 1241 that the RRH can be modified in transit by an attacker on the path. 1242 It has to be noted that such an attacker (for example any MR in the 1243 Mobile Network) can perform more effective attacks than modifying the 1244 RRH. 1246 11.1 IPsec Processing 1247 The IPsec [7] AH [8] and ESP [9] can be used in tunnel mode to 1248 provide different security services to the tunnel between a MR and 1249 its HA. ESP tunnel mode SHOULD be used to provide confidentiality and 1250 authentication to the inner packet. AH tunnel mode MUST be used to 1251 provide authentication of the outer IP header fields, especially the 1252 Routing Headers. 1254 11.1.1 Routing Header type 2 1256 Due to the possible usage of Doors [5] to enable IPv4 traversal, the 1257 Routing Header type 2 cannot be treated as type 0 for the purpose of 1258 IPsec processing (i.e. it cannot be included in its intierity in the 1259 Integrity Check Value (ICV) computation, because NAT/PAT may mangle 1260 one of the MR care-of-addresses along the HA-MR path. 1262 The sender (the HA) will put the slot 0 entry (the MR Home Address) 1263 of the RH as destination of the outer packet, will zero out 1264 completely the Routing Header and will perform the ICV computation. 1266 The receiver (the MR) will put the slot 0 entry as destination of the 1267 outer packet, will zero out the Routing Header and will perform the 1268 ICV verification. 1270 11.1.2 Routing Header type 4 1272 The Routing Header type 4 is "partially mutable", and as such can be 1273 included in the Authentication Data calculation. Given the way type 4 1274 is processed, the sender cannot order the field so that it appears as 1275 it will at the receiver; this means the receiver will have to shuffle 1276 the fields. 1278 The sender (the MR) will zero out all the slots and the Segment Used 1279 field of the RRH, and will put as source address of the outer packet 1280 its Home Address, and then will perform the ICV computation. 1282 The receiver (the HA) will put the entry in slot 0 (the MR Home 1283 Address) in the source address and will zero out all the slots and 1284 the Segment Used field of the RRH, and then will perform the ICV 1285 verification. 1287 11.2 New Threats 1289 The RH type 4 is used to construct a MIPv6 RH type 2 with additional 1290 semantics, as described in Section 4.1. Since RH type 2 becomes a 1291 multi hop option like RH type 0, care must be applied to avoid the 1292 spoofing attack that can be performed with the IPv4 source route 1293 option. This is why IPv6 [10] takes special care in responding to 1294 packets carrying Routing Headers. 1296 AH authenticates the MR Home Address identity and the RRH sequence 1297 number. The RRH sequence number is to be used to check the freshness 1298 of the RRH; anti-replay protection can be obtained if the receiver 1299 enables the anti-replay service of AH [8]. 1301 In particular, if IPSec is being used, the content is protected and 1302 can not be read or modified, so there is no point in redirecting the 1303 traffic just to screen it. 1305 Say a MR in a nested structure modifies the RRH in order to bomb a 1306 target outside of the tree. If that MR forwards the packet with 1307 itself as source address, the MR above it will make sure that the 1308 response packets come back to the attacker first, since that source 1309 is prepended to the RRH. If it forges the source address, then the 1310 ingress filtering at the MR above it should detect the irregularity 1311 and drop the packet. Same if the attacker is actually TLMR. The 1312 conclusion is that ingress filtering is recommended at MR and AR. 1314 Say that an attacker in the infrastructure and on the path of the 1315 MRHA tunnel modifies the RRH in order to redirect the response 1316 packets and bomb a target. Considering the position of the attacker - 1317 a compromised access or core router - there's a lot more it could do 1318 to send perturbations to the traffic, like changing source and 1319 destinations of packets on the fly or eventually polute the routing 1320 protocols. 1322 Say a MR in a nested structure modifies the RH 2 in order to attack a 1323 target outside of the tree. The RH type 2 forwarding rules make sure 1324 that the packet can only go down a tree. So unless the attacker is 1325 TLMR, the packet will not be forwarded. In any case, the attacker 1326 will be bombed first. 1328 Say that an attacker on the path of the MRHA tunnel modifies the RRH 1329 in order to black out the MR. The result could actually be 1330 accomplished by changing any bit in the packet since the IPSec 1331 signature would fail, or scrambling the radio waves in the case of 1332 wireless. 1334 Selecting the tree to attach to is a security critical operation 1335 outside of the scope of this draft. Note that the MR should not 1336 select a path based on trust but rather on measured service. If a 1337 better bandwidth is obtained via an untrusted access using IPSec, 1338 isn't it better than a good willing low bandwidth trusted access? 1340 12. Acknowledgements 1342 The authors wish to thank David Auerbach, Fred Baker, Dana Blair, 1343 Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur, 1344 Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick 1345 Wetterwald -last but not least :)-. 1347 References 1349 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1350 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 1351 2003. 1353 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1354 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 1356 [3] kniveton, t., "Mobile Router Support with Mobile IP", 1357 draft-kniveton-mobrtr-02 (work in progress), July 2002. 1359 [4] Deering, S. and B. Zill, "Redundant Address Deletion when 1360 Encapsulating IPv6 in IPv6", 1361 draft-deering-ipv6-encap-addr-deletion-00 (work in progress), 1362 November 2001. 1364 [5] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for 1365 MIPv6 based Mobile Routers", 1366 draft-thubert-nemo-ipv4-traversal-01 (work in progress), May 1367 2003. 1369 [6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1370 1981. 1372 [7] Kent, S. and R. Atkinson, "Security Architecture for the 1373 Internet Protocol", RFC 2401, November 1998. 1375 [8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1376 November 1998. 1378 [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1379 (ESP)", RFC 2406, November 1998. 1381 [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1382 Specification", RFC 2460, December 1998. 1384 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1385 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1387 [12] Conta, A. and S. Deering, "Internet Control Message Protocol 1388 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1389 Specification", RFC 2463, December 1998. 1391 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an 1392 On-line Database", RFC 3232, January 2002. 1394 Authors' Addresses 1396 Pascal Thubert 1397 Cisco Systems Technology Center 1398 Village d'Entreprises Green Side 1399 400, Avenue Roumanille 1400 Biot - Sophia Antipolis 06410 1401 FRANCE 1403 EMail: pthubert@cisco.com 1405 Marco Molteni 1406 Cisco Systems Technology Center 1407 Village d'Entreprises Green Side 1408 400, Avenue Roumanille 1409 Biot - Sophia Antipolis 06410 1410 FRANCE 1412 EMail: mmolteni@cisco.com 1414 Appendix A. Optimizations 1416 A.1 Path Optimization with RRH 1418 The body of the draft presents RRH as a header that circulates in the 1419 reverse tunnel exclusively. The RRH format by itself has no such 1420 limitation. This section illustrates a potential optimization for 1421 end-to-end traffic between a Mobile Network Node and its 1422 Correspondent Node. 1424 The MNN determines that it is part of a Mobile Network by screening 1425 the Tree Information option in the RA messages from its Attachment 1426 Router. In particular, the MNN knows the TreeDepth as advertised by 1427 the AR. An initial test phase could be derived from MIPv6 to decide 1428 whether optimization with a given CN is possible. 1430 When an MNN performs end-to-end optimization with a CN, the MNN 1431 inserts an empty RRH inside its packets, as opposed to tunneling them 1432 home, which is the default behavior of a Mobile Host as described in 1433 Section 10. 1435 The number of slots in the RRH is initially the AR treeDepth plus 1, 1436 but all slots are clear as opposed to the MR process as described in 1437 Section 9. The source address in the header is the MNN address, and 1438 the destination is the CN. 1440 The AR of the MNN is by definition an MR. Since an RRH is already 1441 present in the packet, the MR does not put the packets from the MNN 1442 on its reverse tunnel, but acts as an intermediate MR; it adds the 1443 source address of the packet (the MNN's address) in the RRH (in slot 1444 0) and stamps its careOf instead in the IP header source address 1445 field. Recursively, all the MRs on a nested network trace in path in 1446 the RRH and take over the source IP. 1448 The support required on the CN side extends MIPv6 in a way similar to 1449 the extension that this draft proposes for the HA side. The CN is 1450 required to parse the RRH when it is valid, refresh its BCE 1451 accordingly, and include an RH type 2 with the full path to its 1452 packets to the MNN. 1454 Note that there is no Bind Update between the MNN and the CN. The RRH 1455 must be secured based on tokens exchanged in the test phase. For the 1456 sake of security, it may be necessary to add fields to the RRH or to 1457 add a separate option in the Mobility Header. 1459 A.2 Packet Size Optimization 1461 RRH allows to update the Correspondent BCE on a per packet basis, 1462 which is the highest resolution that we can achieve. While this may 1463 cope with highly mobile and nested configurations, it can also be an 1464 overkill in some situations. 1466 The RRH comes at a cost: it requires processing in all intermediate 1467 Mobile Routers and in the Correspondent Node. Also, a RRH increases 1468 the packet size by more than the size of an IP address per hop in the 1469 Mobile Network. 1471 This is why an additional Routing Header is proposed (type 3). The 1472 semantics of type 3 are very close to type 4 but: 1474 o Type 3 has only one slot, for the Home Address of the source. 1476 o When it can not add the source to the RH type 3 of an outbound 1477 packet, an intermediate MR: 1479 * MR MUST NOT send ICMP (RRH too small) 1481 * MUST NOT put the packet in a reverse tunnel 1483 Rather, it simply overwrites the source and forwards the packet up 1484 the tree as if the RRH had been properly updated. 1486 o Since the path information is not available, the correspondent 1487 MUST NOT update its BCE based on the RH type 3. The CN (or HA) 1488 identifies the source from the entry in slot 0 and may reconstruct 1489 the initial packet using the CareOf in slot 1 as source for AH 1490 purposes. 1492 /* MR processing on outbound packet with RH type 3 support */ 1493 { 1495 if no RH type 3 or 4 in outer header /* First Mobile Router specific */ 1496 or RH type 4 present but saturated { /* Need a nested encapsulation */ 1498 if RRH is saturated { 1499 do ICMP back (RRH too small) 1500 } 1502 /* put packet in sliding reverse tunnel */ 1503 insert new IP header plus RRH 1504 set source address to the MR Home Address 1505 set destination address to the MR Home Agent Address 1506 add an RRH with all slots zeroed out 1507 compute IPsec AH on the resulting packet 1508 } 1510 /* All MRs including first */ 1511 if packet size > MTU { 1512 do ICMP back (Packet too Big) 1513 } else if RRH { 1514 select first free slot in RRH bottom up 1515 set it to source address from IP header 1516 overwrite source address in IP header with MR CareOf 1517 transmit packet 1518 } else if RH type 3 { 1519 if slot 0 is still free { 1520 /* this is end-to-end optimization */ 1521 set it to source address from IP header 1522 } 1523 overwrite source address in IP header with MR CareOf 1524 transmit packet 1525 } 1526 } 1528 A.2.1 Routing Header Type 3 (Home Address option replacement) 1530 This is an RH-based alternative to the Home Address destination 1531 option. Its usage is described in Appendix A.2. 1533 The decision to send RH type 3 or type 4 is up to the source of the 1534 RRH. Several algorithms may apply, one out of N being the simplest. 1536 IPsec HA processing is done as described in Section 11.1 for Type 4. 1538 The Type 3 Routing Header has the following format: 1540 0 1 2 3 1541 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 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Next Header | Hdr Ext Len | Routing Type=3| Segments Used | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | Reserved | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | | 1548 + + 1549 | | 1550 + Home Address + 1551 | | 1552 + + 1553 | | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 Next Header 1558 8-bit selector. Identifies the type of header immediately 1559 following the Routing header. Uses the same values as the IPv4 1560 Protocol field [13]. 1562 Hdr Ext Len 1564 8-bit unsigned integer. Length of the Routing header in 8-octet 1565 units, not including the first 8 octets. For the Type 3 Routing 1566 header, Hdr Ext Len is always 2. 1568 Routing Type 1570 8-bit unsigned integer. Set to 3. 1572 Segment Used 1574 8-bit unsigned integer. Number of slots used. Either 0 or 1. When 1575 the field is zero, then there is no MR on the path and it is valid 1576 for a CN that does not support RRH to ignore this header. 1578 Reserved 1580 32-bit reserved field. Initialized to zero for transmission; 1581 ignored on reception. 1583 Home Address 1585 128-bit home address of the source of the packet. 1587 Appendix B. Multi Homing 1589 B.1 Multi-Homed Mobile Network 1591 Consider difference between situation A and B in this diagram: 1593 ===?== ==?=== 1594 MR1 MR2 1595 | | 1596 ==?=====?== ==?====== situation A 1597 MR3 MR4 MR5 1598 | | | 1599 === === === 1601 ===?== ==?=== 1602 MR1 MR2 1603 | | 1604 ==?=====?=======?====== situation B 1605 MR3 MR4 MR5 1606 | | | 1607 === === === 1609 Going from A to B, MR5 may now choose between MR1 and MR2 for its 1610 Attachment (default) Router. In terms of Tree Information, MR5, as 1611 well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once MR5 1612 selects its AR, MR2, say, MR5 belongs to the associated tree and 1613 whether MR1 can be reached or not makes no difference. 1615 As long as each MR has a single default router for all its outbound 1616 traffic, 2 different logical trees can be mapped over the physical 1617 configurations in both situations, and once the trees are 1618 established, both cases are equivalent for the processing of RRH. 1620 Note that MR5 MUST use a CareOf based on a prefix owned by its AR as 1621 source of the reverse tunnel, even if other prefixes are present on 1622 the Mobile Network, to ensure that a RH type 2 can be securely routed 1623 back. 1625 B.2 Multihomed Mobile Router 1627 Consider the difference between situation B and C in this diagram: 1629 ===?== ==?=== 1630 MR1 MR2 1631 | | 1632 ==?=====?=======?====== situation B 1633 MR3 MR4 MR5 1634 | | | 1635 === === === 1637 ==? ?== 1638 MR1 1639 | 1640 ==?=====?=======?====== situation C 1641 MR3 MR4 MR5 1642 | | | 1643 === === === 1645 In situation C, MR2's egress interface and its properties are 1646 migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home 1647 Agents, and 2 active interfaces. 1649 If MR1 uses both CareOf addresses at a given point of time, and if 1650 they belong to different prefixes to be used via different attachment 1651 routers, then MR1 actually belongs to 2 trees. It must perform some 1652 routing logic to decide whether to forward packets on either egress 1653 interface. Also, it MUST advertise both tree information sets in its 1654 RA messages. 1656 The difference between situations C and B is that when an attached 1657 router (MR5, say) selects a tree and forwards egress packets via MR1, 1658 it can not be sure that MR1 will actually forward the packets over 1659 that tree. If MR5 has selected a given tree for a specific reason, 1660 then a new source route header is needed to enforce that path on MR1. 1662 The other way around, MR5 may leave the decision up to MR1. If MR1 1663 uses the same attachment router for a given flow or at least a given 1664 destination, then the destination receives consistent RRHs. 1665 Otherwise, the BCE cache will flap, but as both paths are valid, the 1666 traffic still makes it through. 1668 Appendix C. Changes from Previous Version of the Draft 1670 From -03 to -04 1672 TI option: renamed the F (fixed) flag bit to G (grounded). 1674 Binding Update: Made clear that the BU flow conforms MIPv6 and 1675 Nemo but that RRH replaces both Home address Option and Alternate 1676 CareOf option. 1678 From -02 to -03 1680 Reworded the security part to remove an ambiguity that let the 1681 reader think that RRH is unsafe. 1683 From -01 to -02 1685 Made optional the usage of ICMP warning "RRH too small" (Section 1686 5). 1688 Changed the IPsec processing for Routing Header type 2 (Section 1689 11.1). 1691 From -00 to -01 1693 Added new Tree Information Option fields: 1695 A 8 bits Bandwidth indication that provides an idea of the 1696 egress bandwidth. 1698 A CRC-32 that changes with the egress path out of the tree. 1700 a 32 bits unsigned integer, built by each MR out of a high 1701 order configured preference and 24 bits random constant. This 1702 can help as a tie break in Attachment Router selection. 1704 Reduced the 'negative' part of the lollipop space to 0..255 1706 Fixed acknowledgements (sorry Patrick :) 1708 Changed the type of Tree Information Option from 7 to 10. 1710 Intellectual Property Statement 1712 The IETF takes no position regarding the validity or scope of any 1713 intellectual property or other rights that might be claimed to 1714 pertain to the implementation or use of the technology described in 1715 this document or the extent to which any license under such rights 1716 might or might not be available; neither does it represent that it 1717 has made any effort to identify any such rights. Information on the 1718 IETF's procedures with respect to rights in standards-track and 1719 standards-related documentation can be found in BCP-11. Copies of 1720 claims of rights made available for publication and any assurances of 1721 licenses to be made available, or the result of an attempt made to 1722 obtain a general license or permission for the use of such 1723 proprietary rights by implementors or users of this specification can 1724 be obtained from the IETF Secretariat. 1726 The IETF invites any interested party to bring to its attention any 1727 copyrights, patents or patent applications, or other proprietary 1728 rights which may cover technology that may be required to practice 1729 this standard. Please address the information to the IETF Executive 1730 Director. 1732 Full Copyright Statement 1734 Copyright (C) The Internet Society (2004). All Rights Reserved. 1736 This document and translations of it may be copied and furnished to 1737 others, and derivative works that comment on or otherwise explain it 1738 or assist in its implementation may be prepared, copied, published 1739 and distributed, in whole or in part, without restriction of any 1740 kind, provided that the above copyright notice and this paragraph are 1741 included on all such copies and derivative works. However, this 1742 document itself may not be modified in any way, such as by removing 1743 the copyright notice or references to the Internet Society or other 1744 Internet organizations, except as needed for the purpose of 1745 developing Internet standards in which case the procedures for 1746 copyrights defined in the Internet Standards process must be 1747 followed, or as required to translate it into languages other than 1748 English. 1750 The limited permissions granted above are perpetual and will not be 1751 revoked by the Internet Society or its successors or assignees. 1753 This document and the information contained herein is provided on an 1754 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1755 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1756 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1757 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1758 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1760 Acknowledgement 1762 Funding for the RFC Editor function is currently provided by the 1763 Internet Society.