idnits 2.17.1 draft-thubert-nemo-reverse-routing-header-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1699. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 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 648: '...e RH type 0, and the RH type 0 MUST be...' RFC 2119 keyword, line 700: '...slots in the RRH MUST NOT be larger th...' RFC 2119 keyword, line 712: '... slot in the RRH MAY send that ICMP "R...' RFC 2119 keyword, line 716: '...he RRH. The Proposed Size MUST NOT be...' RFC 2119 keyword, line 724: '...stination and it MUST NOT forward it t...' (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 (September 28, 2006) is 6420 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 592, but not defined == Unused Reference: '5' is defined on line 1296, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1300, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-05 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-05 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-03 ** Obsolete normative reference: RFC 2401 (ref. '10') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '11') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '12') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2460 (ref. '13') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '14') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2463 (ref. '15') (Obsoleted by RFC 4443) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '16') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '17') ** Obsolete normative reference: RFC 3775 (ref. '18') (Obsoleted by RFC 6275) Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Thubert 3 Internet-Draft M. Molteni 4 Expires: April 1, 2007 Cisco Systems 5 September 28, 2006 7 IPv6 Reverse Routing Header and its application to Mobile Networks 8 draft-thubert-nemo-reverse-routing-header-06 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 1, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 NEMO basic support enables Mobile Networks by extending Mobile IP to 42 Mobile Routers. In the case of nested Mobile Networks, this involves 43 the overhead of nested tunnels between the Mobile Routers and their 44 Home Agents, and causes a number of security issues. 46 This proposal alleviates those problems as well as other minor ones, 47 by using a source routing within the mobile nested structure, 48 introducing a new routing header, called the reverse routing header. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Recursive complexity . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology and Assumptions . . . . . . . . . . . . . . . . 5 55 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. An Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. New Routing Headers . . . . . . . . . . . . . . . . . . . . 11 59 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . 11 60 4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . 13 61 4.3 Extension Header order . . . . . . . . . . . . . . . . . . 16 62 5. Optimum number of slots in RRH . . . . . . . . . . . . . . . 18 63 6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 20 64 6.1 Modified Router Advertisement Message Format . . . . . . . 20 65 7. MIPv6 flows . . . . . . . . . . . . . . . . . . . . . . . . 21 66 7.1 DHAAD . . . . . . . . . . . . . . . . . . . . . . . . . . 21 67 7.2 Binding Updates . . . . . . . . . . . . . . . . . . . . . 21 68 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 22 69 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 24 70 9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 24 71 9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 25 72 9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 25 73 9.4 Processing of the extended Routing Header Type 2 . . . . . 26 74 9.5 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 28 75 10. Mobile Host Operation . . . . . . . . . . . . . . . . . . . 28 76 11. Security Considerations . . . . . . . . . . . . . . . . . . 29 77 11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . 29 78 11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . 29 79 11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . 29 80 11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . 31 81 12. IANA considerations . . . . . . . . . . . . . . . . . . . . 32 82 13. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 32 83 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 15.1 informative reference . . . . . . . . . . . . . . . . . 33 86 15.2 normative reference . . . . . . . . . . . . . . . . . . 33 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 88 A. Optimizations . . . . . . . . . . . . . . . . . . . . . . . 35 89 A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 35 90 A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 36 91 A.2.1 Routing Header Type 3 (Home Address option 92 replacement) . . . . . . . . . . . . . . . . . . . . . 37 93 B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . . 39 94 B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 39 95 B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 41 96 C. Changes from Previous Version of the Draft . . . . . . . . . 42 97 Intellectual Property and Copyright Statements . . . . . . . 44 99 1. Introduction 101 This document assumes that the reader is familiar with the Mobile 102 Networks terminology defined in [17] and [4], with Mobile IPv6 103 defined in [18], and with the NEMO basic support defined in [19]. 105 Generally a Mobile Network may be either solid (a network with one 106 mobile router) or nested, single or multi-homed. This proposal 107 starts from the assumption that nested Mobile Networks will be the 108 norm, and so presents a solution that avoids the tunnel within tunnel 109 overhead of already existing proposals. 111 The solution is based on a single, telescopic tunnel between the 112 first Mobile Router (MR) to forward a packet and its Home Agent (HA). 113 By using IPsec ESP on that tunnel, home equivalent privacy is 114 obtained without further encapsulation. 116 The solution introduces a new Routing Header (RH), called the Reverse 117 Routing Header (RRH), to perform source routing within the mobile 118 structure. RRH is a variant of IPv4 Loose Source and Record Route 119 (LSRR) [9] adapted for IPv6. RRH records the route out of the nested 120 Mobile Network and can be trivially converted into a routing header 121 for packets destined to the Mobile Network. 123 This version focuses on single-homed Mobile Networks. Hints for 124 further optimizations and multi-homing are given in the appendixes. 126 Local Fixed Node (LFN) and Correspondent Node (CN) operations are 127 left unchanged from Mobile IPv6 [18]. Specifically the CN can also 128 be a LFN. 130 Section 3 proposes an example to illustrate the operation of the 131 proposed solution, leaving detailed specifications to the remaining 132 chapters. The reader may refer to Section 2.1 for the specific 133 terminology. 135 1.1 Recursive complexity 137 A number of drafts and publications suggest -or can be extended to- a 138 model where the Home Agent and any arbitrary Correspondent would 139 actually get individual binding from the chain of nested Mobile 140 Routers, and form a routing header appropriately. 142 An intermediate MR would keep track of all the pending communications 143 between hosts in its subtree of Mobile Networks and their CNs, and a 144 binding message to each CN each time it changes its point of 145 attachment. 147 If this was done, then each CN, by receiving all the binding messages 148 and processing them recursively, could infer a partial topology of 149 the nested Mobile Network, sufficient to build a multi-hop routing 150 header for packets sent to nodes inside the nested Mobile Network. 152 However, this extension has a cost: 154 1. Binding Update storm 156 when one MR changes its point of attachment, it needs to send a 157 BU to all the CNs of each node behind him. When the Mobile 158 Network is nested, the number of nodes and relative CNs can be 159 huge, leading to congestions and drops. 161 2. Protocol Hacks 163 Also, in order to send the BUs, the MR has to keep track of all 164 the traffic it forwards to maintain his list of CNs. In case of 165 IPSec tunneled traffic, that CN information may not be available. 167 3. CN operation 169 The computation burden of the CN becomes heavy, because it has to 170 analyze each BU in a recursive fashion in order to infer nested 171 Mobile Network topology required to build a multi hop routing 172 header. 174 4. Missing BU 176 If a CN doesn't receive the full set of PSBU sent by the MR, it 177 will not be able to infer the full path to a node inside the 178 nested Mobile Network. The RH will be incomplete and the packet 179 may or may not be delivered. 181 5. Obsolete BU 183 If the Binding messages are sent asynchronously by each MR, then, 184 when the relative position of MRs and/or the TLMR point of 185 attachment change rapidly, the image of Mobile Network that the 186 CN maintains is highly unstable. If only one BU in the chain is 187 obsolete due to the movement of an intermediate MR, the 188 connectivity may be lost. 190 A conclusion is that the path information must be somehow aggregated 191 to provide the CN with consistent snapshots of the full path across 192 the Mobile Network. This can be achieved by an IPv6 form of loose 193 source / record route header, that we introduce here as a Reverse 194 Routing Header 196 2. Terminology and Assumptions 198 2.1 Terminology 200 This document assumes that the reader is familiar with Mobile IPv6 as 201 defined in [18] and with the concept of Mobile Router defined in the 202 NEMO terminology document [4]. In particular, the "Nested Mobility 203 Terms" introduced in the NEMO terminology are repeatedly used in this 204 document. 206 Solid Mobile Network: 208 One or more IP subnets attached to a MR and mobile as a unit, with 209 respect to the rest of the Internet. A Solid Mobile Network can 210 be either singly or multi-homed. A Solid Mobile Network may be 211 composed of more then one link and may interconnect several 212 routers, but all routers in the Solid Mobile Network are fixed 213 with respect to each other. 215 We like to represent a simple single-homed Mobile Network as an 216 hanger, because it has only one uplink hook and a bar to which 217 multiple hooks can be attached. Graphically we use the question 218 mark "?" to show the uplink hook (interface) connected to the MR, 219 and the "=" sign to represent the bar: 221 ? 222 MR1 223 | 224 =============== 226 IPv6 Mobile Host: 228 A IPv6 Host, with support for MIPv6 MN, and the additional NEMO 229 capability described in this draft. 231 Home prefix 233 Network prefix, which identifies the home link within the Internet 234 topology. 236 Mobile Network prefix 238 Network prefix, common to all IP addresses in the Mobile Network 239 when the MR is attached to the home link. It may or may not be a 240 subset of the Home subnet prefix. 242 Inbound direction: 244 direction from outside the Mobile Network to inside 246 Outbound direction: 248 direction from inside the Mobile Network to outside 250 RRH: 252 Reverse Routing Header, defined in this specification 254 NULL RRH: 256 A NULL RRH is an RRH with a null "Segments Used" field 258 2.2 Assumptions 260 We make the following assumptions: 262 1. A MR has one Home Agent and one Home Address -> one primary CoA. 264 2. A MR attaches to a single Attachment Router as default router. 266 3. A MR may have more than one uplink interface. 268 4. An interface can be either wired or wireless. The text assumes 269 that interfaces are wireless for generality. 271 5. Each Solid Mobile Network may have more that one L2 Access Point, 272 all of them controlled by the same Attachment Router, which we 273 assume to be the Mobile Router. 275 Since an MR has only one primary CoA, only one uplink interface can 276 be used at a given point of time. Since the MR attaches to a single 277 attachment router, if due care is applied to avoid loops, then the 278 resulting topology is a tree. 280 3. An Example 282 The nested Mobile Network in the following figure has a tree 283 topology, according to the assumptions in Section 2.2. In the tree 284 each node is a Solid Mobile Network, represented by its MR. 286 +---------------------+ 287 | Internet |---CN 288 +---------------|-----+ 289 / Access Router 290 MR3_HA | 291 ======?====== 292 MR1 293 | 294 ====?=============?==============?=== 295 MR5 MR2 MR6 296 | | | 297 =========== ===?========= ============= 298 MR3 299 | 300 ==|=========?== <-- Mobile Network3 301 LFN1 MR4 302 | 303 ========= 305 An example nested Mobile Network 307 This example focuses on a Mobile Network node at depth 3 (Mobile 308 Network3) inside the tree, represented by its mobile router MR3. The 309 path to the Top Level Mobile Router (TLMR) MR1 and then the Internet 310 is 312 MR3 -> MR2 -> MR1 -> Internet 314 Consider the case where a LFN belonging to Mobile Network3 sends a 315 packet to a CN in the Internet, and the CN replies back. With the 316 tunnel within tunnel approach described by [19], we would have three 317 bi-directional nested tunnels: 319 -----------. 320 --------/ /-----------. 321 -------/ | | /-------- 322 CN ------( - - | - - - | - - - | - - - | - - (----- LFN 323 MR3_HA -------\ | | \-------- MR3 324 MR2_HA --------\ \----------- MR2 325 MR1_HA ----------- MR1 327 Depending on the relative location of MR1_HA, MR2_HA and MR3_HA, this 328 may lead to a very inefficient "pinball" routing in the 329 Infrastructure. 331 On the other hand, with the RRH approach we would have only one bi- 332 directional tunnel: 334 --------------------------- MR1 ---- MR2 ---- MR3 335 CN ------( - - - - - - - - - - - - - - (------- LFN 336 MR3_HA --------------------------- MR1 ---- MR2 ---- MR3 338 The first mobile router on the path, MR3, in addition to tunneling 339 the packet to its HA, adds a reverse routing header with N = 3 pre- 340 allocated slots. Choosing the right value for N is discussed in 341 Section 5. The bottom slot is equivalent to the MIPv6 Home Address 342 option. MR3 inserts its home address MR3_HoA into slot 0. 344 The outer packet has source MR3's Care of Address, MR3_CoA, and 345 destination MR3's Home Agent, MR3_HA: 347 <-------------- outer IPv6 header --------------------> 348 +-------+-------++ -- ++----+-------+-------+---------+ +------- 349 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 350 |MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET 351 | | |: :| 4 | | | | | 352 +-------+-------++ -- ++----+-------+-------+---------+ +------- 354 The second router on the path, MR2, notices that the packet already 355 contains an RRH, and so it overwrites the source address of the 356 packet with its own address, MR2_CoA, putting the old source address, 357 MR3_CoA, in the first free slot of the RRH. 359 The outer packet now has source MR2_CoA and destination MR3_HA; the 360 RRH from top to bottom is MR3_CoA | MR3_HoA: 362 <-------------- outer IPv6 header --------------------> 363 +-------+-------++ -- ++----+-------+-------+---------+ +------- 364 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 365 |MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA|MR3_HoA | |iPACKET 366 | | |: :| 4 | | | | | 367 +-------+-------++ -- ++----+-------+-------+---------+ +------- 368 In general the process followed by the second router is repeated by 369 all the routers on the path, including the TLMR (in this example 370 MR1). When the packet leaves MR1 the source address is MR1_CoA and 371 the RRH is MR2_CoA | MR3_CoA | MR3_HoA: 373 <-------------- outer IPv6 header --------------------> 374 +-------+-------++ -- ++----+-------+-------+---------+ +------- 375 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 376 |MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET 377 | | |: :| 4 | | | | | 378 +-------+-------++ -- ++----+-------+-------+---------+ +------- 380 In a colloquial way we may say that while the packet travels from MR3 381 to MR3_HA, the Mobile Network tunnel end point "telescopes" from MR3 382 to MR2 to MR1. 384 When the home agent MR3_HA receives the packet it notices that it 385 contains a RRH and it looks at the bottom entry, MR3_HoA. This entry 386 is used as if it were a MIPv6 Home Address destination option, i.e. 387 as an index into the Binding Cache. When decapsulating the inner 388 packet the home agent performs the checks described in Section 8, and 389 if successful it forwards the inner packet to CN. 391 MR3_HA stores two items in the Bind Cache Entry associated with MR3: 392 the address entries from RRH, to be used to build the RH, and the 393 packet source address MR1_CoA, to be used as the first hop. 395 Further packets from the CN to the LFN are plain IPv6 packets. 396 Destination is LFN, and so the packet reaches MR3's home network. 398 MR3_HA intercepts it, does a Bind Cache prefix lookup and obtains as 399 match the MR3 entry, containing the first hop and the information 400 required to build the RH. It then puts the packet in the tunnel 401 MR3_HA -- MR3 as follows: source address MR3_HA and destination 402 address the first hop, MR1_CoA. The RH is trivially built out of the 403 previous RRH: MR2_CoA | MR3_CoA | MR3_HoA: 405 <-------------- outer IPv6 header --------------------> 406 +-------+-------++ -- ++----+-------+-------+---------+ +------- 407 |oSRC |oDST |: :|oRH | | | | | 408 |MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET 409 | | |: :| 2 | | | | | 410 +-------+-------++ -- ++----+-------+-------+---------+ +------- 411 The packet is routed with plain IP routing up to the first 412 destination MR1_CoA. 414 The RH of the outer packet is type 2 as in MIPv6 [18], but has 415 additional semantics inherited from type 0: it contains the path 416 information to traverse the nested Mobile Network from the TLMR to 417 the tunnel endpoint MR3. Each intermediate destination forwards the 418 packet to the following destination in the routing header. The 419 security aspects of this are treated in Section 11.2. 421 MR1, which is the initial destination in the IP header, looks at the 422 RH and processes it according to Section 9, updating the RH and the 423 destination and sending it to MR2_CoA. MR2 does the same and so on 424 until the packet reaches the tunnel endpoint, MR3. 426 When the packet reaches MR3, the source address in the IP header is 427 MR3_HA, the destination is MR3_CoA and in the RH there is one segment 428 left, MR3_HoA. As a consequence the packet belongs to the MR3_HA -- 429 MR3 tunnel. MR3 decapsulates the inner packet, applying the rules 430 described in Section 9 and sends it to LFN. The packet that reaches 431 LFN is the plain IPv6 packet that was sent by CN. 433 4. New Routing Headers 435 This draft modifies the MIPv6 Routing Header type 2 and introduces 436 two new Routing Headers, type 3 and 4. Type 3, which is an 437 optimization of type 4 will be discussed in Appendix A.2.1. The 438 draft presents their operation in the context of Mobile Routers 439 although the formats are not tied to Mobile IP and could be used in 440 other situations. 442 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) 444 Mobile IPv6 uses a Routing header to carry the Home Address for 445 packets sent from a Correspondent Node to a Mobile Node. In [18], 446 this Routing header (Type 2) is restricted to carry only one IPv6 447 address. The format proposed here extends the Routing Header type 2 448 to be multi-hop. 450 The processing of the multi-hop RH type 2 inherits from the RH type 0 451 described in IPv6 [13]. Specifically: the restriction on multicast 452 addresses is the same; a RH type 2 is not examined or processed until 453 it reaches the node identified in the Destination Address field of 454 the IPv6 header; in that node, the RH type 0 algorithm applies, with 455 added security checks. 457 The construction of the multi-hop RH type 2 by the HA is described in 458 Section 8; the processing by the MRs is described in Section 9.4; and 459 the security aspects are treated in Section 11.2. 461 The destination node of a packet containing a RH type 2 can be a MR 462 or some other kind of node. If it is a MR it will perform the 463 algorithm described in Section 9.4, otherwise it will operate as 464 prescribed by IPv6 [13] when the routing type is unrecognized. 466 The multi-hop Routing Header type 2, as extended by this draft, has 467 the following format: 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Next Header | Hdr Ext Len | Routing Type=2| Segments Left | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Reserved | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 + + 478 | | 479 + Address[1] + 480 | | 481 + + 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 + + 486 | | 487 + Address[2] + 488 | | 489 + + 490 | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 . . . 493 . . . 494 . . . 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | | 497 + + 498 | | 499 + Address[n] + 500 | | 501 + + 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Next Header 507 8-bit selector. Identifies the type of header immediately 508 following the Routing header. Uses the same values as the IPv4 509 Protocol field [16]. 511 Hdr Ext Len 513 8-bit unsigned integer. Length of the Routing header in 8-octet 514 units, not including the first 8 octets. For the Type 2 Routing 515 header, Hdr Ext Len is equal to two times the number of addresses 516 in the header. 518 Routing Type 520 8-bit unsigned integer. Set to 2. 522 Segments Left 524 8-bit unsigned integer. Number of route segments remaining, i.e., 525 number of explicitly listed intermediate nodes still to be visited 526 before reaching the final destination. 528 Reserved 530 32-bit reserved field. Initialized to zero for transmission; 531 ignored on reception. 533 Address[1..n] 535 Vector of 128-bit addresses, numbered 1 to n. 537 4.2 Routing Header Type 4 (The Reverse Routing Header) 539 The Routing Header type 4, or Reverse Routing Header (RRH), is a 540 variant of IPv4 loose source and record route (LSRR) [9] adapted for 541 IPv6. 543 Addresses are added from bottom to top (0 to n-1 in the picture). 544 The RRH is designed to help the destination build an RH for the 545 return path. 547 When a RRH is present in a packet, the rule for upper-layer checksum 548 computing is that the source address used in the pseudo-header is 549 that of the original source, located in the slot 0 of the RRH, unless 550 the RRH slot 0 is empty, in which case the source in the IP header of 551 the packet is used. 553 As the 'segment left' field of the generic RH is reassigned to the 554 number of segments used, an IPv6 node that does not support RRH will 555 discard the packet, unless the RRH is empty. 557 The RRH contains n pre-allocated address slots, to be filled by each 558 MR in the path. It is possible to optimize the number of slots using 559 the Tree Information Option described in Section 5. 561 The Type 4 Routing Header has the following format: 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Next Header | Hdr Ext Len | Routing Type=4| Segments Used | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Sequence Number | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 + + 572 | | 573 + Slot[n-1] + 574 | | 575 + + 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 . . . 579 . . . 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | | 582 + + 583 | | 584 + Slot[1] (1st MR CoA) + 585 | | 586 + + 587 | | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | | 590 + + 591 | | 592 + Slot[0] (Home address) + 593 | | 594 + + 595 | | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Next Header 600 8-bit selector. Identifies the type of header immediately 601 following the Routing header. Uses the same values as the IPv4 602 Protocol field [16]. 604 Hdr Ext Len 606 8-bit unsigned integer. Length of the Routing header in 8-octet 607 units, not including the first 8 octets. For the Type 4 Routing 608 header, Hdr Ext Len is equal to two times the number of addresses 609 in the header. 611 Routing Type 613 8-bit unsigned integer. Set to 4. 615 Segments Used 617 8-bit unsigned integer. Number of slots used. Initially set to 1 618 by the MR when only the Home Address is there. Incremented by the 619 MRs on the way as they add the packets source addresses to the 620 RRH. 622 Sequence Number 624 32-bit unsigned integer. The Sequence Number starts at 0, and is 625 incremented by the source upon each individual packet. Using the 626 Radia Perlman's lollipop algorithm, values between 0 and 255 are 627 'negative', left to indicate a reboot or the loss of HA 628 connectivity, and are skipped when wrapping and upon positive 629 Binding Ack. The sequence number is used to check the freshness of 630 the RRH; anti-replay protection is left to IPsec AH. 632 Slot[n-1..0] 634 Vector of 128-bit addresses, numbered n-1 to 0. 636 When applied to the NEMO problem, the RRH can be used to update the 637 HA on the actual location of the MR. Only MRs forwarding packets on 638 an egress interface while not at home update it on the fly. 640 A RRH is inserted by the first MR on the Mobile Network outbound 641 path, as part of the reverse tunnel encapsulation; it is removed by 642 the associated HA when the tunneled packet is decapsulated. 644 4.3 Extension Header order 646 The RH type 2 is to be placed as any RH as described in [13] section 647 4.1. If a RH type 0 is present in the packet, then the RH type 2 is 648 placed immediately after the RH type 0, and the RH type 0 MUST be 649 consumed before the RH type 2. 651 RH type 3 and 4 are mutually exclusive. They are to be placed right 652 after the Hop-by-Hop Options header if any, or else right after the 653 IPv6 header. 655 As a result, the order prescribed in section 4.1 of RFC 2460 becomes: 657 IPv6 header 659 Hop-by-Hop Options header 661 Routing header type 3 or 4 663 Destination Options header (note 1) 665 Routing header type 0 667 Routing header type 2 669 Fragment header 671 Authentication header (note 2) 673 Encapsulating Security Payload header (note 2) 675 Destination Options header (note 3) 677 upper-layer header 679 5. Optimum number of slots in RRH 681 If its current Attachment Router conforms to Tree Discovery as 682 specified in [7], a MR knows its current tree depth from the Tree 683 Information Option (RA-TIO). The maximum number of slots needed in 684 the RRH is the same value as the MR's own tree depth (that is the 685 TreeDepth as received from the AR incremented by one). 687 When sending a Binding Update, a MR always reinitializes the number 688 of slots in the RRH to the maximum of DEF_RRH_SLOTS and its tree 689 depth, if the latter is known from a reliable hint such as RA-TIO. 690 The message may have a number of unused (NULL) slots, when it is 691 received by the Home Agent. The HA crops out the extra entries in 692 order to send a RH of type 2 back with its response. The RH type 2 693 in the resulting Binding Ack contains the number of required slots 694 that the MR now uses until it gets a hint that the topology changes 695 or until the next Binding update. 697 In the case of a NULL RRH, the HA does not include a RH 2 at all. 698 This may happen in the process of a DHAAD message (see Section 7.1) 700 The number of slots in the RRH MUST NOT be larger than MAX_RRH_SLOTS. 701 If a MR is deeper in a tree then MAX_RRH_SLOTS, the packets will be 702 reencapsulated by a MR up high in the tree, or dropped, depending on 703 that MR security policy. 705 In runtime, it may happen that the RRH has fewer slots than required 706 for the number of MRs in the path because either the nested Mobile 707 Network topology is changing too quickly, or the MR that inserted the 708 RRH had a wrong representation of the topology. 710 To solve this problem a new ICMP message is introduced, "RRH 711 Warning", type 64. A MR on the tree egress path that gets a packet 712 without a free slot in the RRH MAY send that ICMP "RRH warning" back 713 to the MR that inserted the RRH in the first place. 715 This message allows a MR on the path to propose a larger number of 716 slots to the MR that creates the RRH. The Proposed Size MUST NOT be 717 larger than MAX_RRH_SLOTS. The originating MR must rate-limit the 718 ICMP messages to avoid excessive ICMP traffic in the case of the 719 source failing to operate as requested. 721 The originating MR must insert an RH type 2 based on the RRH in the 722 associated IP header, in order to route the ICMP message back to the 723 source of the reverse tunnel. A MR that receives this ICMP message 724 is the actual destination and it MUST NOT forward it to the (LFN) 725 source of the tunneled packet. 727 The type 64 ICMP has the following format: 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Type = 64 | Code = 0 | Checksum | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Current Size | Proposed Size | Reserved | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | As much of invoking packet | 737 + as will fit without the ICMPv6 packet + 738 | exceeding the minimum IPv6 MTU | 739 . . 740 . . 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 Type 745 64 [To Be Assigned] 747 Code 0: RRH too small 749 The originating MR requires the source to set the RRH size to a 750 larger value. The packet that triggered the ICMP will still be 751 forwarded by the MR, but the path cannot be totally optimized (see 752 Section 9.3). 754 Checksum 756 The ICMP checksum [15]. 758 Current Size 760 RRH size of the invoking packet, as a reference. 762 Proposed Size 764 The new value, expressed as a number of IPv6 addresses that can 765 fit in the RRH. 767 Reserved 769 16-bit reserved field. Initialized to zero for transmission; 770 ignored on reception. 772 6. Modifications to IPv6 Neighbor Discovery 774 6.1 Modified Router Advertisement Message Format 776 Mobile IPv6 [18] modifies the format of the Router Advertisement 777 message [14] by the addition of a single flag bit (H) to indicate 778 that the router sending the Advertisement message is serving as a 779 home agent on this link. 781 This draft adds another single flag bit (N) to indicate that the 782 router sending the advertisement message is a MR. This means that 783 the link on which the message is sent is a Mobile Network, which may 784 or may not be at home. 786 The Router Advertisement message has the following format: 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Type | Code | Checksum | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Reachable Time | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Retrans Timer | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Options ... 800 +-+-+-+-+-+-+-+-+-+-+-+- 802 This format represents the following changes over that originally 803 specified for Neighbor Discovery [14]: 805 Home Agent (H) 807 The Home Agent (H) bit is set in a Router Advertisement to 808 indicate that the router sending this Router Advertisement is also 809 functioning as a Mobile IP home agent on this link. 811 NEMO Capable (N) 813 The NEMO Capable (N) bit is set in a Router Advertisement to 814 indicate that the router sending this Router Advertisement is also 815 functioning as a Mobile Router on this link, so that the link is a 816 Mobile Network, possibly away from home. 818 7. MIPv6 flows 820 7.1 DHAAD 822 Conforming MIPv6 [18], a MR normally does not identify itself in its 823 DHAAD messages, using a Home Address option. For the same reason, a 824 RRH with a Home address in slot 0 is not required here, either. Yet, 825 this specification allows a MR to send its DHAAD messages with a NULL 826 RRH, as opposed to no RRH at all. 828 This is generally useful if the attachment router is not bound yet, 829 for whatever reason, and more specifically in the case of the Mobile 830 Home Network as described in [3]. In the latter case, an HA is 831 mobile and may happen to be located under one of its MRs (within its 832 subtree), which is a dead lock for the NEMO basic support.. 834 Since MRs may forward packets with an RRH even if themselves are not 835 bound yet, the packets from nested MRs can be forwarded and the 836 responses are source routed back, allowing the nested MRs to bind. 837 In particular, if a nested MR is also a mobile Home Agent, it becomes 838 reachable from its own MRs, which breaks the deadlock. 840 Also, this alleviates the need for the attachment router to forward 841 DHAAD messages across its own MRHA tunnel. 843 HAs MUST respond by reversing the RRH into a RH2 if a RRH is present 844 and not NULL. A NULL RRH is ignored. 846 7.2 Binding Updates 848 A MIPv6 or NEMO Binding Update provides more information than just 849 the path in the nested cloud so they are still used as described in 850 MIPv6 [18] for Home Registration and de-registration. The only 851 difference when using a RRH is that the Home Address Destination 852 Option and the alternate CareOf MIP option MUST be omitted. 854 The Binding Update flow is also used to update the optimum size of 855 the RRH, as described in Section 5. 857 The HA MUST save the RRH in its binding cache, either in the original 858 form or in the form of an RH type 2, ready to be added to the tunnel 859 header of the MRHA packets. The RRH format is very close to that of 860 the RH type 2, designed to minimize the process of the transmutation. 862 8. Home Agent Operation 864 This section inherits from chapter 10 of MIPv6 [18], which is kept 865 unmodified except for parts 10.5 and 10.6 which are extended. This 866 draft mostly adds the opportunity for a MN to update the Binding 867 Cache of its Home Agent using RRH, though it does not change the fact 868 that MNs still need to select a home agent, register and deregister 869 to it, using the MIP Bind Update. 871 This draft extends [18] section 10.6 as follows: 873 o The entry point of the tunnel is now checked against the TLMR as 874 opposed to the primary CoA. 876 o The Binding Cache can be updated based on RRH with proper AH 877 authentication. 879 As further explained in Section 7.2, this specification modifies MIP 880 so that the HA can rely on the RH type 4 (RRH) to update its Bind 881 Cache Entry (BCE), when the Mobile Node moves. The conceptual 882 content of the BCE is extended to contain a sequence counter, and the 883 sequence of hops within the --potentially nested-- Mobile Network to 884 a given Mobile Node. The sequence counter is initially set to 0. 886 When the HA receives a packet destined to itself, it checks for the 887 presence of a Routing Header of type 3 or 4. Both contain as least 888 the entry for the home address of the MN in slot 0; this replaces the 889 MIP Home Address Option and allows the HA to determine the actual 890 source of the packet, to access the corresponding security 891 association. 893 As explained in Section 11.2, the HA MUST verify the authenticity of 894 the packet using IPSEC AH and drop packets that were not issued by 895 the proper Mobile Node. An RRH is considered only if the packet is 896 authenticated and if its sequence number is higher than the one saved 897 in the BCE. 899 Also, an RRH is considered only if an initial Bind Update exchange 900 has been successfully completed between the Mobile Node and its Home 901 Agent for Home Registration. If the RRH is valid, then the Bind 902 Cache Entry is revalidated for a lifetime as configured from the 903 initial Bind Update. 905 The BCE abstract data is updated as follows: 907 The first hop for the return path is the last hop on the path of 908 the incoming packet, that is between the HA and the Top Level 909 Mobile Router (TLMR) of the Mobile Network. The HA saves the IP 910 address of the TLMR from the source field in the IP header. 912 The rest of the path to the MN is found in the RRH. 914 The sequence counter semantics is changed as described in 915 Section 4.2 917 This draft extends [18] section 10.5 as follows: 919 A Home Agent advertises the prefixes of its registered Mobile 920 Routers, during the registration period, on the local Interior 921 Gateway Protocol (IGP). 923 The Routing Header type 2 is extended to be multi-hop. 925 The Home Agent is extended to support routes to prefixes that are 926 owned by Mobile Routers. This can be configured statically, or can 927 be exchanged using a routing protocol as in [19], which is out of the 928 scope of this document. As a consequence of this process, the Home 929 Agent which is selected by a Mobile Router advertises reachability of 930 the MR prefixes for the duration of the registration over the local 931 IGP. 933 When a HA gets a packet for which the destination is a node behind a 934 Mobile Router, it places the packet in the tunnel to the associated 935 MR. This ends up with a packet which destination address in the IP 936 Header is the TLMR, and with a Routing Header of type 2 for the rest 937 of the way to the Mobile Router, which may be multi-hop. 939 To build the RH type 2 from the RRH, the HA sets the type to 2, and 940 clears the bits 32-63 (byte 4 to 7). 942 9. Mobile Router Operation 944 This section inherits from chapter 11 of [18], which is extended to 945 support Mobile Networks and Mobile Routers as a specific case of 946 Mobile Node. 948 This draft extends section 11.2.1 of MIPv6 [18] as follows: 950 o When not at home, an MR uses a reverse tunnel with its HA for all 951 the traffic that is sourced in its mobile network(s); traffic 952 originated further down a nested network is not tunneled twice but 953 for exception cases. 955 o The full path to and within the Mobile Network is piggy-backed 956 with the traffic on a per-packet basis to cope with rapid 957 movement. This makes the packet construction different from 958 MIPv6. 960 The MR when not at home sets up a bi-directional tunnel with its HA. 961 The reverse direction MR -> HA is needed to assure transparent 962 topological correctness to LFNs, as in [19]. But, as opposed to the 963 NEMO Basic Support, nested tunnels are generally avoided. 965 9.1 Processing of ICMP "RRH too small" 967 The New ICMP message "RRH too Small" is presented in Section 5. This 968 message is addressed to the MR which performs the tunnel 969 encapsulation and generates the RRH. 971 Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate 972 it to the originating LFN or inner tunnel source, but MUST process it 973 for itself. 975 If the Current Size in the ICMP messages matches the actual current 976 number of slots in RRH, and if the ICMP passes some safety checks as 977 described in Section 5, then the MR MAY adapt the number of slots to 978 the Proposed Size. 980 9.2 Processing of ICMP error 982 ICMP back { 984 if RRH is present { 985 compute RH type 2 based on RRH 986 get packet source from IP header 987 send ICMP error to source including RH type 2. 988 } 989 else { 990 get packet source from IP header 991 send ICMP error to source with no RH. 992 } 993 } 995 When the MR receives an ICMP error message, it checks whether it is 996 the final destination of the packet by looking at the included 997 packet. If the included packet has an RRH, then the MR will use the 998 RRH to forward the ICMP to the original source of the packet. 1000 9.3 Processing of RHH for Outbound Packets 1002 The forwarding of a packet with a non saturated RRH consists in fact 1003 in passing the hot potato to the attachment router, which does not 1004 require the MRHA tunnel to be up. 1006 So, it happens as soon as a MR has selected its attachment router and 1007 before the binding flow has actually taken place. Also, this process 1008 is much safer since the packet is not forwarded home. 1010 if no RRH in outer header /* First Mobile Router specific */ 1011 or RRH present but saturated { /* Need a nested encapsulation */ 1013 if RRH is saturated { 1014 do ICMP back (RRH too small) 1015 } 1017 /* put packet in sliding reverse tunnel if bound */ 1018 if reverse tunnel is established { 1019 insert new IP header plus RRH 1020 set source address to the MR Home Address 1021 set destination address to the MR Home Agent Address 1022 add an RRH with all slots zeroed out 1023 compute IPsec AH on the resulting packet 1024 } else return 1025 } 1027 /* All MRs including first, even if not bound home */ 1028 if packet size <= MTU { 1029 select first free slot in RRH bottom up 1030 set it to source address from IP header 1031 overwrite source address in IP header with MR CareOf 1032 transmit packet 1033 } else { 1034 do ICMP back (Packet too Big) 1035 } 1037 If the packet already contains an RRH in the outer header, and has a 1038 spare slot, the MR adds the source address from the packet IP header 1039 to the RRH and overwrites the source address in the IP header with 1040 its CoA. As a result, the packets are always topologically correct. 1042 Else, if the RRH is present but is saturated, and therefore the 1043 source IP can not be added, the MR sends a ICMP 'RRH too small' to 1044 the tunnel endpoint which originated the outer packet, using the RRH 1045 info to route it back. The ICMP message is a warning, and the packet 1046 is not discarded. Rather, the MR does a nested encapsulation of the 1047 packet in its own reverse tunnel home with an additional RRH. 1049 Else, if the packet does not have an RRH, the MR puts it in its 1050 reverse tunnel, sourced at the CoA, with an RRH indicating in slot 0 1051 the Home Address of the MR, and with proper IPsec AH as described 1052 further in Section 11.1. 1054 9.4 Processing of the extended Routing Header Type 2 1056 if Segments Left = 0 { 1057 /* new check: packet must be looped back internally */ 1058 if packet doesn't come from a loopback interface { 1059 discard the packet 1060 return 1061 } 1063 proceed to process the next header in the packet, whose type is 1064 identified by the Next Header field in the Routing header 1065 } 1066 else if Hdr Ext Len is odd { 1067 send an ICMP Parameter Problem, Code 0, message to the Source 1068 Address, pointing to the Hdr Ext Len field, and discard the 1069 packet 1070 } 1071 else { 1072 compute n, the number of addresses in the Routing header, by 1073 dividing Hdr Ext Len by 2 1075 if Segments Left is greater than n { 1076 send an ICMP Parameter Problem, Code 0, message to the Source 1077 Address, pointing to the Segments Left field, and discard the 1078 packet 1079 } 1080 else { 1081 decrement Segments Left by 1; 1083 compute i, the index of the next address to be visited in 1084 the address vector, by subtracting Segments Left from n 1086 if Address [i] or the IPv6 Destination Address is multicast { 1087 discard the packet 1088 } 1089 else { 1090 /* new security check */ 1091 if Address [i] doesn't belong to one of the MNP { 1092 discard the packet 1093 return 1094 } 1096 /* new check: keep MIPv6 behavior prevent packets from being 1097 * forwarded outside the node. 1098 */ 1099 if Segments Left is 0 and Address[i] isn't the node's own 1100 home address { 1101 discard the packet 1102 return 1103 } 1104 swap the IPv6 Destination Address and Address[i] 1105 if the IPv6 Hop Limit is less than or equal to 1 { 1106 send an ICMP Time Exceeded -- Hop Limit Exceeded in 1107 Transit message to the Source Address and discard the 1108 packet 1109 } 1110 else { 1111 decrement the Hop Limit by 1 1112 resubmit the packet to the IPv6 module for transmission 1113 to the new destination; 1114 } 1115 } 1116 } 1117 } 1119 9.5 Decapsulation 1121 A MR when decapsulating a packet from its HA must perform the 1122 following checks 1124 1. Destination address 1126 The destination address of the inner packet must belong to one of 1127 the Mobile Network prefixes. 1129 10. Mobile Host Operation 1131 When it is at Home, a Mobile Host issues packets with source set to 1132 its home address and with destination set to its CN, in a plain IPv6 1133 format. 1135 When a MH is not at home but is attached to a foreign link in the 1136 Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to 1137 manage its mobility. 1139 When a MH is visiting a foreign Mobile Network, it forwards its 1140 outbound packets over the reverse tunnel (including RRH) to its HA. 1141 One can view that operation as a first MR process applied on a plain 1142 IPv6 packet issued by a LFN. 1144 As a result, the encapsulating header include: 1146 with source set to the MH COA and destination set to the MH HA 1148 with slot 0 set to the MH Home Address 1150 The inner packet is the plain IPv6 packet from the MH Home Address to 1151 the CN. 1153 11. Security Considerations 1155 This section is not complete; further work is needed to analyze and 1156 solve the security problems of record and source route. 1158 Compared to MIPv6, the main security problem seems to be the fact 1159 that the RRH can be modified in transit by an attacker on the path. 1160 It has to be noted that such an attacker (for example any MR in the 1161 Mobile Network) can perform more effective attacks than modifying the 1162 RRH. 1164 11.1 IPsec Processing 1166 The IPsec [10] AH [11] and ESP [12] can be used in tunnel mode to 1167 provide different security services to the tunnel between a MR and 1168 its HA. ESP tunnel mode SHOULD be used to provide confidentiality 1169 and authentication to the inner packet. AH tunnel mode MUST be used 1170 to provide authentication of the outer IP header fields, especially 1171 the Routing Headers. 1173 11.1.1 Routing Header type 2 1175 Due to the possible usage of Doors [8] to enable IPv4 traversal, the 1176 Routing Header type 2 cannot be treated as type 0 for the purpose of 1177 IPsec processing (i.e. it cannot be included in its intirety in the 1178 Integrity Check Value (ICV) computation, because NAT/PAT may mangle 1179 one of the MR care-of-addresses along the HA-MR path. 1181 The sender (the HA) will put the slot 0 entry (the MR Home Address) 1182 of the RH as destination of the outer packet, will zero out 1183 completely the Routing Header and will perform the ICV computation. 1185 The receiver (the MR) will put the slot 0 entry as destination of the 1186 outer packet, will zero out the Routing Header and will perform the 1187 ICV validation. 1189 11.1.2 Routing Header type 4 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 [13] 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 [11]. 1220 In particular, if IPSec is being used, the content is protected and 1221 can not be read or modified, so there is no point in redirecting the 1222 traffic just to screen it. 1224 Say a MR in a nested structure modifies the RRH in order to bomb a 1225 target outside of the tree. If that MR forwards the packet with 1226 itself as source address, the MR above it will make sure that the 1227 response packets come back to the attacker first, since that source 1228 is prepended to the RRH. If it forges the source address, then the 1229 ingress filtering at the MR above it should detect the irregularity 1230 and drop the packet. Same if the attacker is actually TLMR. The 1231 conclusion is that ingress filtering is recommended at MR and AR. 1233 Say that an attacker in the infrastructure and on the path of the 1234 MRHA tunnel modifies the RRH in order to redirect the response 1235 packets and bomb a target. Considering the position of the attacker 1236 - a compromised access or core router - there's a lot more it could 1237 do to send perturbations to the traffic, like changing source and 1238 destinations of packets on the fly or eventually pollute the routing 1239 protocols. 1241 Say a MR in a nested structure modifies the RH 2 in order to attack a 1242 target outside of the tree. The RH type 2 forwarding rules make sure 1243 that the packet can only go down a tree. So unless the attacker is 1244 TLMR, the packet will not be forwarded. In any case, the attacker 1245 will be bombed first. 1247 Say that an attacker on the path of the MRHA tunnel modifies the RRH 1248 in order to black out the MR. The result could actually be 1249 accomplished by changing any bit in the packet since the IPSec 1250 signature would fail, or scrambling the radio waves in the case of 1251 wireless. 1253 Selecting the tree to attach to is a security critical operation 1254 outside of the scope of this draft. Note that the MR should not 1255 select a path based on trust but rather on measured service. If a 1256 better bandwidth is obtained via an untrusted access using IPSec, 1257 isn't it better than a good willing low bandwidth trusted access? 1259 12. IANA considerations 1261 This document requires IANA to define 2 new IPv6 Routing Header 1262 types. 1264 13. Protocol Constants 1266 DEF_RRH_SLOTS: 7 1268 MAX_RRH_SLOTS: 10 1270 14. Acknowledgements 1272 The authors wish to thank David Auerbach, Fred Baker, Dana Blair, 1273 Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur, 1274 Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick 1275 Wetterwald -last but not least :)-. 1277 15. References 1279 15.1 informative reference 1281 [1] Devarapalli, V., "Local HA to HA protocol", 1282 draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), 1283 March 2006. 1285 [2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 1286 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 1287 progress), May 2006. 1289 [3] Thubert, P., "NEMO Home Network models", 1290 draft-ietf-nemo-home-network-models-06 (work in progress), 1291 February 2006. 1293 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1294 draft-ietf-nemo-terminology-05 (work in progress), March 2006. 1296 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 1297 draft-ietf-nemo-requirements-05 (work in progress), 1298 October 2005. 1300 [6] Ng, C., "Analysis of Multihoming in Network Mobility Support", 1301 draft-ietf-nemo-multihoming-issues-06 (work in progress), 1302 June 2006. 1304 [7] Thubert, P., "Nested Nemo Tree Discovery", 1305 draft-thubert-tree-discovery-03 (work in progress), April 2006. 1307 [8] Thubert, P., Molteni, M., and P. Wetterwald, "IPv4 traversal for 1308 MIPv6 based Mobile Routers", 1309 draft-thubert-nemo-ipv4-traversal-01 (work in progress), 1310 May 2003. 1312 15.2 normative reference 1314 [9] Postel, J., "Internet Protocol", STD 5, RFC 791, 1315 September 1981. 1317 [10] Kent, S. and R. Atkinson, "Security Architecture for the 1318 Internet Protocol", RFC 2401, November 1998. 1320 [11] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1321 November 1998. 1323 [12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1324 (ESP)", RFC 2406, November 1998. 1326 [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1327 Specification", RFC 2460, December 1998. 1329 [14] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1330 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1332 [15] Conta, A. and S. Deering, "Internet Control Message Protocol 1333 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1334 Specification", RFC 2463, December 1998. 1336 [16] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 1337 line Database", RFC 3232, January 2002. 1339 [17] Manner, J. and M. Kojo, "Mobility Related Terminology", 1340 RFC 3753, June 2004. 1342 [18] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1343 IPv6", RFC 3775, June 2004. 1345 [19] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1346 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1347 January 2005. 1349 Authors' Addresses 1351 Pascal Thubert 1352 Cisco Systems Technology Center 1353 Village d'Entreprises Green Side 1354 400, Avenue Roumanille 1355 Biot - Sophia Antipolis 06410 1356 FRANCE 1358 Email: pthubert@cisco.com 1360 Marco Molteni 1361 Cisco Systems Technology Center 1362 Village d'Entreprises Green Side 1363 400, Avenue Roumanille 1364 Biot - Sophia Antipolis 06410 1365 FRANCE 1367 Email: mmolteni@cisco.com 1369 Appendix A. Optimizations 1371 A.1 Path Optimization with RRH 1373 The body of the draft presents RRH as a header that circulates in the 1374 reverse tunnel exclusively. The RRH format by itself has no such 1375 limitation. This section illustrates a potential optimization for 1376 end-to-end traffic between a Mobile Network Node and its 1377 Correspondent Node. 1379 The MNN determines that it is part of a Mobile Network by screening 1380 the Tree Information option in the RA messages from its Attachment 1381 Router. In particular, the MNN knows the TreeDepth as advertised by 1382 the AR. An initial test phase could be derived from MIPv6 to decide 1383 whether optimization with a given CN is possible. 1385 When an MNN performs end-to-end optimization with a CN, the MNN 1386 inserts an empty RRH inside its packets, as opposed to tunneling them 1387 home, which is the default behavior of a Mobile Host as described in 1388 Section 10. 1390 The number of slots in the RRH is initially the AR treeDepth plus 1, 1391 but all slots are clear as opposed to the MR process as described in 1392 Section 9. The source address in the header is the MNN address, and 1393 the destination is the CN. 1395 The AR of the MNN is by definition an MR. Since an RRH is already 1396 present in the packet, the MR does not put the packets from the MNN 1397 on its reverse tunnel, but acts as an intermediate MR; it adds the 1398 source address of the packet (the MNN's address) in the RRH (in slot 1399 0) and stamps its careOf instead in the IP header source address 1400 field. Recursively, all the MRs on a nested network trace in path in 1401 the RRH and take over the source IP. 1403 The support required on the CN side extends MIPv6 in a way similar to 1404 the extension that this draft proposes for the HA side. The CN is 1405 required to parse the RRH when it is valid, refresh its BCE 1406 accordingly, and include an RH type 2 with the full path to its 1407 packets to the MNN. 1409 Note that there is no Bind Update between the MNN and the CN. The 1410 RRH must be secured based on tokens exchanged in the test phase. For 1411 the sake of security, it may be necessary to add fields to the RRH or 1412 to add a separate option in the Mobility Header. 1414 A.2 Packet Size Optimization 1416 RRH allows to update the Correspondent BCE on a per packet basis, 1417 which is the highest resolution that we can achieve. While this may 1418 cope with highly mobile and nested configurations, it can also be an 1419 overkill in some situations. 1421 The RRH comes at a cost: it requires processing in all intermediate 1422 Mobile Routers and in the Correspondent Node. Also, a RRH increases 1423 the packet size by more than the size of an IP address per hop in the 1424 Mobile Network. 1426 This is why an additional Routing Header is proposed (type 3). The 1427 semantics of type 3 are very close to type 4 but: 1429 o Type 3 has only one slot, for the Home Address of the source. 1431 o When it can not add the source to the RH type 3 of an outbound 1432 packet, an intermediate MR: 1434 * MR MUST NOT send ICMP (RRH too small) 1436 * MUST NOT put the packet in a reverse tunnel 1438 Rather, it simply overwrites the source and forwards the packet up 1439 the tree as if the RRH had been properly updated. 1441 o Since the path information is not available, the correspondent 1442 MUST NOT update its BCE based on the RH type 3. The CN (or HA) 1443 identifies the source from the entry in slot 0 and may reconstruct 1444 the initial packet using the CareOf in slot 1 as source for AH 1445 purposes. 1447 /* MR processing on outbound packet with RH type 3 support */ 1448 { 1450 if no RH type 3 or 4 in outer header /* Case of first MR */ 1451 or RH type 4 present but saturated { /* Causing nested encap */ 1453 if RRH is saturated { 1454 do ICMP back (RRH too small) 1455 } 1457 /* put packet in sliding reverse tunnel */ 1458 insert new IP header plus RRH 1459 set source address to the MR Home Address 1460 set destination address to the MR Home Agent Address 1461 add an RRH with all slots zeroed out 1462 compute IPsec AH on the resulting packet 1463 } 1465 /* All MRs including first */ 1466 if packet size > MTU { 1467 do ICMP back (Packet too Big) 1468 } else if RRH { 1469 select first free slot in RRH bottom up 1470 set it to source address from IP header 1471 overwrite source address in IP header with MR CareOf 1472 transmit packet 1473 } else if RH type 3 { 1474 if slot 0 is still free { 1475 /* this is end-to-end optimization */ 1476 set it to source address from IP header 1477 } 1478 overwrite source address in IP header with MR CareOf 1479 transmit packet 1480 } 1481 } 1483 A.2.1 Routing Header Type 3 (Home Address option replacement) 1485 This is an RH-based alternative to the Home Address destination 1486 option. Its usage is described in Appendix A.2. 1488 The decision to send RH type 3 or type 4 is up to the source of the 1489 RRH. Several algorithms may apply, one out of N being the simplest. 1491 IPsec HA processing is done as described in Section 11.1 for Type 4. 1493 The Type 3 Routing Header has the following format: 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Next Header | Hdr Ext Len | Routing Type=3| Segments Used | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Reserved | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | | 1503 + + 1504 | | 1505 + Home Address + 1506 | | 1507 + + 1508 | | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 Next Header 1513 8-bit selector. Identifies the type of header immediately 1514 following the Routing header. Uses the same values as the IPv4 1515 Protocol field [16]. 1517 Hdr Ext Len 1519 8-bit unsigned integer. Length of the Routing header in 8-octet 1520 units, not including the first 8 octets. For the Type 3 Routing 1521 header, Hdr Ext Len is always 2. 1523 Routing Type 1525 8-bit unsigned integer. Set to 3. 1527 Segment Used 1529 8-bit unsigned integer. Number of slots used. Either 0 or 1. 1530 When the field is zero, then there is no MR on the path and it is 1531 valid for a CN that does not support RRH to ignore this header. 1533 Reserved 1535 32-bit reserved field. Initialized to zero for transmission; 1536 ignored on reception. 1538 Home Address 1540 128-bit home address of the source of the packet. 1542 Appendix B. Multi Homing 1544 B.1 Multi-Homed Mobile Network 1546 Consider difference between situation A and B in this diagram: 1548 ===?== ==?=== 1549 MR1 MR2 1550 | | 1551 ==?=====?== ==?====== situation A 1552 MR3 MR4 MR5 1553 | | | 1554 === === === 1556 ===?== ==?=== 1557 MR1 MR2 1558 | | 1559 ==?=====?=======?====== situation B 1560 MR3 MR4 MR5 1561 | | | 1562 === === === 1564 Going from A to B, MR5 may now choose between MR1 and MR2 for its 1565 Attachment (default) Router. In terms of Tree Information, MR5, as 1566 well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once 1567 MR5 selects its AR, MR2, say, MR5 belongs to the associated tree and 1568 whether MR1 can be reached or not makes no difference. 1570 As long as each MR has a single default router for all its outbound 1571 traffic, 2 different logical trees can be mapped over the physical 1572 configurations in both situations, and once the trees are 1573 established, both cases are equivalent for the processing of RRH. 1575 Note that MR5 MUST use a CareOf based on a prefix owned by its AR as 1576 source of the reverse tunnel, even if other prefixes are present on 1577 the Mobile Network, to ensure that a RH type 2 can be securely routed 1578 back. 1580 B.2 Multihomed Mobile Router 1582 Consider the difference between situation B and C in this diagram: 1584 ===?== ==?=== 1585 MR1 MR2 1586 | | 1587 ==?=====?=======?====== situation B 1588 MR3 MR4 MR5 1589 | | | 1590 === === === 1592 ==? ?== 1593 MR1 1594 | 1595 ==?=====?=======?====== situation C 1596 MR3 MR4 MR5 1597 | | | 1598 === === === 1600 In situation C, MR2's egress interface and its properties are 1601 migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home 1602 Agents, and 2 active interfaces. 1604 If MR1 uses both CareOf addresses at a given point of time, and if 1605 they belong to different prefixes to be used via different attachment 1606 routers, then MR1 actually belongs to 2 trees. It must perform some 1607 routing logic to decide whether to forward packets on either egress 1608 interface. Also, it MUST advertise both tree information sets in its 1609 RA messages. 1611 The difference between situations C and B is that when an attached 1612 router (MR5, say) selects a tree and forwards egress packets via MR1, 1613 it can not be sure that MR1 will actually forward the packets over 1614 that tree. If MR5 has selected a given tree for a specific reason, 1615 then a new source route header is needed to enforce that path on MR1. 1617 The other way around, MR5 may leave the decision up to MR1. If MR1 1618 uses the same attachment router for a given flow or at least a given 1619 destination, then the destination receives consistent RRHs. 1620 Otherwise, the BCE cache will flap, but as both paths are valid, the 1621 traffic still makes it through. 1623 Appendix C. Changes from Previous Version of the Draft 1625 From -04 to -05 1627 Tree Information option: now a reference to a separate draft. 1629 Removed RRH heartbeat. 1631 Added a DHAAD section 1633 Clarified how RRH solves the mobile home deadlock. 1635 new section "Optimum number of slots in RRH" from ICMP section 1637 From -03 to -04 1639 TI option: renamed the F (fixed) flag bit to G (grounded). 1641 Binding Update: Made clear that the BU flow conforms MIPv6 and 1642 NEMO but that RRH replaces both Home address Option and Alternate 1643 CareOf option. 1645 From -02 to -03 1647 Reworded the security part to remove an ambiguity that let the 1648 reader think that RRH is unsafe. 1650 From -01 to -02 1652 Made optional the usage of ICMP warning "RRH too small" 1653 (Section 5). 1655 Changed the IPsec processing for Routing Header type 2 1656 (Section 11.1). 1658 From -00 to -01 1660 Added new Tree Information Option fields: 1662 A 8 bits Bandwidth indication that provides an idea of the 1663 egress bandwidth. 1665 A CRC-32 that changes with the egress path out of the tree. 1667 a 32 bits unsigned integer, built by each MR out of a high 1668 order configured preference and 24 bits random constant. This 1669 can help as a tie break in Attachment Router selection. 1671 Reduced the 'negative' part of the lollipop space to 0..255 1673 Fixed acknowledgements (sorry Patrick :) 1675 Changed the type of Tree Information Option from 7 to 10. 1677 Intellectual Property Statement 1679 The IETF takes no position regarding the validity or scope of any 1680 Intellectual Property Rights or other rights that might be claimed to 1681 pertain to the implementation or use of the technology described in 1682 this document or the extent to which any license under such rights 1683 might or might not be available; nor does it represent that it has 1684 made any independent effort to identify any such rights. Information 1685 on the procedures with respect to rights in RFC documents can be 1686 found in BCP 78 and BCP 79. 1688 Copies of IPR disclosures made to the IETF Secretariat and any 1689 assurances of licenses to be made available, or the result of an 1690 attempt made to obtain a general license or permission for the use of 1691 such proprietary rights by implementers or users of this 1692 specification can be obtained from the IETF on-line IPR repository at 1693 http://www.ietf.org/ipr. 1695 The IETF invites any interested party to bring to its attention any 1696 copyrights, patents or patent applications, or other proprietary 1697 rights that may cover technology that may be required to implement 1698 this standard. Please address the information to the IETF at 1699 ietf-ipr@ietf.org. 1701 Disclaimer of Validity 1703 This document and the information contained herein are provided on an 1704 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1705 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1706 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1707 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1708 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1709 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1711 Copyright Statement 1713 Copyright (C) The Internet Society (2006). This document is subject 1714 to the rights, licenses and restrictions contained in BCP 78, and 1715 except as set forth therein, the authors retain all their rights. 1717 Acknowledgment 1719 Funding for the RFC Editor function is currently provided by the 1720 Internet Society.