idnits 2.17.00 (12 Aug 2021) /tmp/idnits4072/draft-thubert-nemo-reverse-routing-header-05.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1671. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1687), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 644: '...e RH type 0, and the RH type 0 MUST be...' RFC 2119 keyword, line 696: '...slots in the RRH MUST NOT be larger th...' RFC 2119 keyword, line 708: '... slot in the RRH MAY send that ICMP "R...' RFC 2119 keyword, line 712: '...he RRH. The Proposed Size MUST NOT be...' RFC 2119 keyword, line 720: '...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 == Line 1246 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 (June 2004) is 6549 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 ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '3') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '4') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2463 (ref. '7') (Obsoleted by RFC 4443) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '9') ** Obsolete normative reference: RFC 3775 (ref. '10') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '11') == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-00 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: draft-ietf-nemo-home-network-models has been published as RFC 4887 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '14') -- Possible downref: Normative reference to a draft: ref. '15' Summary: 21 errors (**), 0 flaws (~~), 8 warnings (==), 10 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: November 30, 2004 Cisco Systems 4 June 2004 6 IPv6 Reverse Routing Header and its application to Mobile Networks 7 draft-thubert-nemo-reverse-routing-header-05 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 NEMO basic support enables Mobile Networks by extending Mobile IP to 41 Mobile Routers. In the case of nested Mobile Networks, this involves 42 the overhead of nested tunnels between the Mobile Routers and their 43 Home Agents, and causes a number of security issues. 45 This proposal alleviates those problems as well as other minor ones, 46 by using a source routing within the mobile nested structure, 47 introducing a new routing header, called the reverse routing header. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Recursive complexity . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology and Assumptions . . . . . . . . . . . . . . . . 5 54 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. An Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. New Routing Headers . . . . . . . . . . . . . . . . . . . . 11 58 4.1 Routing Header Type 2 (MIPv6 RH with extended semantics) . 11 59 4.2 Routing Header Type 4 (The Reverse Routing Header) . . . . 13 60 4.3 Extension Header order . . . . . . . . . . . . . . . . . . 15 61 5. Optimum number of slots in RRH . . . . . . . . . . . . . . . 17 62 6. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . 19 63 6.1 Modified Router Advertisement Message Format . . . . . . . 19 64 7. MIPv6 flows . . . . . . . . . . . . . . . . . . . . . . . . 20 65 7.1 DHAAD . . . . . . . . . . . . . . . . . . . . . . . . . . 20 66 7.2 Binding Updates . . . . . . . . . . . . . . . . . . . . . 20 67 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 21 68 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . 23 69 9.1 Processing of ICMP "RRH too small" . . . . . . . . . . . . 23 70 9.2 Processing of ICMP error . . . . . . . . . . . . . . . . . 24 71 9.3 Processing of RHH for Outbound Packets . . . . . . . . . . 24 72 9.4 Processing of the extended Routing Header Type 2 . . . . . 25 73 9.5 Decapsulation . . . . . . . . . . . . . . . . . . . . . . 27 74 10. Mobile Host Operation . . . . . . . . . . . . . . . . . . . 27 75 11. Security Considerations . . . . . . . . . . . . . . . . . . 28 76 11.1 IPsec Processing . . . . . . . . . . . . . . . . . . . . 28 77 11.1.1 Routing Header type 2 . . . . . . . . . . . . . . . 28 78 11.1.2 Routing Header type 4 . . . . . . . . . . . . . . . 28 79 11.2 New Threats . . . . . . . . . . . . . . . . . . . . . . 30 80 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 31 81 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 84 A. Optimizations . . . . . . . . . . . . . . . . . . . . . . . 34 85 A.1 Path Optimization with RRH . . . . . . . . . . . . . . . . 34 86 A.2 Packet Size Optimization . . . . . . . . . . . . . . . . . 35 87 A.2.1 Routing Header Type 3 (Home Address option 88 replacement) . . . . . . . . . . . . . . . . . . . . . 36 89 B. Multi Homing . . . . . . . . . . . . . . . . . . . . . . . . 38 90 B.1 Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 38 91 B.2 Multihomed Mobile Router . . . . . . . . . . . . . . . . . 39 92 C. Changes from Previous Version of the Draft . . . . . . . . . 40 93 Intellectual Property and Copyright Statements . . . . . . . 42 95 1. Introduction 97 This document assumes that the reader is familiar with the Mobile 98 Networks terminology defined in [9] and [11], with Mobile IPv6 99 defined in [10], and with the NEMO basic support defined in [12]. 101 Generally a Mobile Network may be either solid (a network with one 102 mobile router) or nested, single or multi-homed. This proposal 103 starts from the assumption that nested Mobile Networks will be the 104 norm, and so presents a solution that avoids the tunnel within tunnel 105 overhead of already existing proposals. 107 The solution is based on a single, telescopic tunnel between the 108 first Mobile Router (MR) to forward a packet and its Home Agent (HA). 109 By using IPsec ESP on that tunnel, home equivalent privacy is 110 obtained without further encapsulation. 112 The solution introduces a new Routing Header (RH), called the Reverse 113 Routing Header (RRH), to perform source routing within the mobile 114 structure. RRH is a variant of IPv4 Loose Source and Record Route 115 (LSRR) [1] adapted for IPv6. RRH records the route out of the nested 116 Mobile Network and can be trivially converted into a routing header 117 for packets destined to the Mobile Network. 119 This version focuses on single-homed Mobile Networks. Hints for 120 further optimizations and multi-homing are given in the appendixes. 122 Local Fixed Node (LFN) and Correspondent Node (CN) operations are 123 left unchanged from Mobile IPv6 [10]. Specifically the CN can also 124 be a LFN. 126 Section 3 proposes an example to illustrate the operation of the 127 proposed solution, leaving detailed specifications to the remaining 128 chapters. The reader may refer to Section 2.1 for the specific 129 terminology. 131 1.1 Recursive complexity 133 A number of drafts and publications suggest -or can be extended to- a 134 model where the Home Agent and any arbitrary Correspondent would 135 actually get individual binding from the chain of nested Mobile 136 Routers, and form a routing header appropriately. 138 An intermediate MR would keep track of all the pending communications 139 between hosts in its subtree of Mobile Networks and their CNs, and a 140 binding message to each CN each time it changes its point of 141 attachment. 143 If this was done, then each CN, by receiving all the binding messages 144 and processing them recursively, could infer a partial topology of 145 the nested Mobile Network, sufficient to build a multi-hop routing 146 header for packets sent to nodes inside the nested Mobile Network. 148 However, this extension has a cost: 150 1. Binding Update storm 152 when one MR changes its point of attachment, it needs to send a 153 BU to all the CNs of each node behind him. When the Mobile 154 Network is nested, the number of nodes and relative CNs can be 155 huge, leading to congestions and drops. 157 2. Protocol Hacks 159 Also, in order to send the BUs, the MR has to keep track of all 160 the traffic it forwards to maintain his list of CNs. In case of 161 IPSec tunneled traffic, that CN information may not be available. 163 3. CN operation 165 The computation burden of the CN becomes heavy, because it has to 166 analyze each BU in a recursive fashion in order to infer nested 167 Mobile Network topology required to build a multi hop routing 168 header. 170 4. Missing BU 172 If a CN doesn't receive the full set of PSBU sent by the MR, it 173 will not be able to infer the full path to a node inside the 174 nested Mobile Network. The RH will be incomplete and the packet 175 may or may not be delivered. 177 5. Obsolete BU 179 If the Binding messages are sent asynchronously by each MR, then, 180 when the relative position of MRs and/or the TLMR point of 181 attachment change rapidly, the image of Mobile Network that the 182 CN maintains is highly unstable. If only one BU in the chain is 183 obsolete due to the movement of an intermediate MR, the 184 connectivity may be lost. 186 A conclusion is that the path information must be somehow aggregated 187 to provide the CN with consistent snapshots of the full path across 188 the Mobile Network. This can be achieved by an IPv6 form of loose 189 source / record route header, that we introduce here as a Reverse 190 Routing Header 192 2. Terminology and Assumptions 194 2.1 Terminology 196 This document assumes that the reader is familiar with Mobile IPv6 as 197 defined in [10] and with the concept of Mobile Router defined in the 198 NEMO terminology document [11]. In particular, the "Nested Mobility 199 Terms" introduced in the NEMO terminology are repeatedly used in this 200 document. 202 Solid Mobile Network: 204 One or more IP subnets attached to a MR and mobile as a unit, with 205 respect to the rest of the Internet. A Solid Mobile Network can 206 be either singly or multi-homed. A Solid Mobile Network may be 207 composed of more then one link and may interconnect several 208 routers, but all routers in the Solid Mobile Network are fixed 209 with respect to each other. 211 We like to represent a simple single-homed Mobile Network as an 212 hanger, because it has only one uplink hook and a bar to which 213 multiple hooks can be attached. Graphically we use the question 214 mark "?" to show the uplink hook (interface) connected to the MR, 215 and the "=" sign to represent the bar: 217 ? 218 MR1 219 | 220 =============== 222 IPv6 Mobile Host: 224 A IPv6 Host, with support for MIPv6 MN, and the additional NEMO 225 capability described in this draft. 227 Home prefix 229 Network prefix, which identifies the home link within the Internet 230 topology. 232 Mobile Network prefix 234 Network prefix, common to all IP addresses in the Mobile Network 235 when the MR is attached to the home link. It may or may not be a 236 subset of the Home subnet prefix. 238 Inbound direction: 240 direction from outside the Mobile Network to inside 242 Outbound direction: 244 direction from inside the Mobile Network to outside 246 RRH: 248 Reverse Routing Header, defined in this specification 250 NULL RRH: 252 A NULL RRH is an RRH with a null "Segments Used" field 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 Solid Mobile Network may have more that one L2 Access Point, 268 all of them controlled by the same Attachment Router, which we 269 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 Solid 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 [12], 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 5. 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 [10], 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 434 draft presents their operation in the context of Mobile Routers 435 although the formats are not tied to Mobile IP and could be used in 436 other 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 [10], 442 this Routing header (Type 2) is restricted to carry only one IPv6 443 address. The format proposed here extends the Routing Header type 2 444 to be multi-hop. 446 The processing of the multi-hop RH type 2 inherits from the RH type 0 447 described in IPv6 [5]. 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.4; 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.4, otherwise it will operate as 460 prescribed by IPv6 [5] 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 [8]. 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) [1] adapted for 537 IPv6. 539 Addresses are added from bottom to top (0 to n-1 in the picture). 540 The RRH is designed to help the destination build an RH for the 541 return 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 5. 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 [8]. 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 626 of 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 [5] 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. Optimum number of slots in RRH 677 If its current Attachment Router conforms to Tree Discovery as 678 specified in [13], a MR knows its current tree depth from the Tree 679 Information Option (RA-TIO). The maximum number of slots needed in 680 the RRH is the same value as the MR's own tree depth (that is the 681 TreeDepth as received from the AR incremented by one). 683 When sending a Binding Update, a MR always reinitializes the number 684 of slots in the RRH to the maximum of DEF_RRH_SLOTS and its tree 685 depth, if the latter is known from a reliable hint such as RA-TIO. 686 The message may have a number of unused (NULL) slots, when it is 687 received by the Home Agent. The HA crops out the extra entries in 688 order to send a RH of type 2 back with its response. The RH type 2 689 in the resulting Binding Ack contains the number of required slots 690 that the MR now uses until it gets a hint that the topology changes 691 or until the next Binding update. 693 In the case of a NULL RRH, the HA does not include a RH 2 at all. 694 This may happen in the process of a DHAAD message (see Section 7.1) 696 The number of slots in the RRH MUST NOT be larger than MAX_RRH_SLOTS. 697 If a MR is deeper in a tree then MAX_RRH_SLOTS, the packets will be 698 reencapsulated by a MR up high in the tree, or dropped, depending on 699 that MR security policy. 701 In runtime, it may happen that the RRH has fewer slots than required 702 for the number of MRs in the path because either the nested Mobile 703 Network topology is changing too quickly, or the MR that inserted the 704 RRH had a wrong representation of the topology. 706 To solve this problem a new ICMP message is introduced, "RRH 707 Warning", type 64. A MR on the tree egress path that gets a packet 708 without a free slot in the RRH MAY send that ICMP "RRH warning" back 709 to the MR that inserted the RRH in the first place. 711 This message allows a MR on the path to propose a larger number of 712 slots to the MR that creates the RRH. The Proposed Size MUST NOT be 713 larger than MAX_RRH_SLOTS. The originating MR must rate-limit the 714 ICMP messages to avoid excessive ICMP traffic in the case of the 715 source failing to operate as requested. 717 The originating MR must insert an RH type 2 based on the RRH in the 718 associated IP header, in order to route the ICMP message back to the 719 source of the reverse tunnel. A MR that receives this ICMP message 720 is the actual destination and it MUST NOT forward it to the (LFN) 721 source of the tunneled packet. 723 The type 64 ICMP has the following format: 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Type = 64 | Code = 0 | Checksum | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Current Size | Proposed Size | Reserved | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | As much of invoking packet | 733 + as will fit without the ICMPv6 packet + 734 | exceeding the minimum IPv6 MTU | 735 . . 736 . . 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Type 741 64 [To Be Assigned] 743 Code 0: RRH too small 745 The originating MR requires the source to set the RRH size to a 746 larger value. The packet that triggered the ICMP will still be 747 forwarded by the MR, but the path cannot be totally optimized (see 748 Section 9.3). 750 Checksum 752 The ICMP checksum [7]. 754 Current Size 756 RRH size of the invoking packet, as a reference. 758 Proposed Size 760 The new value, expressed as a number of IPv6 addresses that can 761 fit in the RRH. 763 Reserved 765 16-bit reserved field. Initialized to zero for transmission; 766 ignored on reception. 768 6. Modifications to IPv6 Neighbor Discovery 770 6.1 Modified Router Advertisement Message Format 772 Mobile IPv6 [10] modifies the format of the Router Advertisement 773 message [6] by the addition of a single flag bit (H) to indicate that 774 the router sending the Advertisement message is serving as a home 775 agent on this link. 777 This draft adds another single flag bit (N) to indicate that the 778 router sending the advertisement message is a MR. This means that 779 the link on which the message is sent is a Mobile Network, which may 780 or may not be at home. 782 The Router Advertisement message has the following format: 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type | Code | Checksum | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Reachable Time | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Retrans Timer | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Options ... 796 +-+-+-+-+-+-+-+-+-+-+-+- 798 This format represents the following changes over that originally 799 specified for Neighbor Discovery [6]: 801 Home Agent (H) 803 The Home Agent (H) bit is set in a Router Advertisement to 804 indicate that the router sending this Router Advertisement is also 805 functioning as a Mobile IP home agent on this link. 807 NEMO Capable (N) 809 The NEMO Capable (N) bit is set in a Router Advertisement to 810 indicate that the router sending this Router Advertisement is also 811 functioning as a Mobile Router on this link, so that the link is a 812 Mobile Network, possibly away from home. 814 7. MIPv6 flows 816 7.1 DHAAD 818 Conforming MIPv6 [10], a MR normally does not identify itself in its 819 DHAAD messages, using a Home Address option. For the same reason, a 820 RRH with a Home address in slot 0 is not required here, either. Yet, 821 this specification allows a MR to send its DHAAD messages with a NULL 822 RRH, as opposed to no RRH at all. 824 This is generally useful if the attachment router is not bound yet, 825 for whatever reason, and more specifically in the case of the Mobile 826 Home Network as described in [14]. In the latter case, an HA is 827 mobile and may happen to be located under one of its MRs (within its 828 subtree), which is a dead lock for the NEMO basic support.. 830 Since MRs may forward packets with an RRH even if themselves are not 831 bound yet, the packets from nested MRs can be forwarded and the 832 responses are source routed back, allowing the nested MRs to bind. 833 In particular, if a nested MR is also a mobile Home Agent, it becomes 834 reachable from its own MRs, which breaks the deadlock. 836 Also, this alleviates the need for the attachment router to forward 837 DHAAD messages across its own MRHA tunnel. 839 HAs MUST respond by reversing the RRH into a RH2 if a RRH is present 840 and not NULL. A NULL RRH is ignored. 842 7.2 Binding Updates 844 A MIPv6 or NEMO Binding Update provides more information than just 845 the path in the nested cloud so they are still used as described in 846 MIPv6 [10] for Home Registration and de-registration. The only 847 difference when using a RRH is that the Home Address Destination 848 Option and the alternate CareOf MIP option MUST be omitted. 850 The Binding Update flow is also used to update the optimum size of 851 the RRH, as described in Section 5. 853 The HA MUST save the RRH in its binding cache, either in the original 854 form or in the form of an RH type 2, ready to be added to the tunnel 855 header of the MRHA packets. The RRH format is very close to that of 856 the RH type 2, designed to minimize the process of the transmutation. 858 8. Home Agent Operation 860 This section inherits from chapter 10 of MIPv6 [10], which is kept 861 unmodified except for parts 10.5 and 10.6 which are extended. This 862 draft mostly adds the opportunity for a MN to update the Binding 863 Cache of its Home Agent using RRH, though it does not change the fact 864 that MNs still need to select a home agent, register and deregister 865 to it, using the MIP Bind Update. 867 This draft extends [10] section 10.6 as follows: 869 o The entry point of the tunnel is now checked against the TLMR as 870 opposed to the primary CoA. 872 o The Binding Cache can be updated based on RRH with proper AH 873 authentication. 875 As further explained in Section 7.2, this specification modifies MIP 876 so that the HA can rely on the RH type 4 (RRH) to update its Bind 877 Cache Entry (BCE), when the Mobile Node moves. The conceptual 878 content of the BCE is extended to contain a sequence counter, and the 879 sequence of hops within the --potentially nested-- Mobile Network to 880 a given Mobile Node. The sequence counter is initially set to 0. 882 When the HA receives a packet destined to itself, it checks for the 883 presence of a Routing Header of type 3 or 4. Both contain as least 884 the entry for the home address of the MN in slot 0; this replaces the 885 MIP Home Address Option and allows the HA to determine the actual 886 source of the packet, to access the corresponding security 887 association. 889 As explained in Section 11.2, the HA MUST verify the authenticity of 890 the packet using IPSEC AH and drop packets that were not issued by 891 the proper Mobile Node. An RRH is considered only if the packet is 892 authenticated and if its sequence number is higher than the one saved 893 in the BCE. 895 Also, an RRH is considered only if an initial Bind Update exchange 896 has been successfully completed between the Mobile Node and its Home 897 Agent for Home Registration. If the RRH is valid, then the Bind 898 Cache Entry is revalidated for a lifetime as configured from the 899 initial Bind Update. 901 The BCE abstract data is updated as follows: 903 The first hop for the return path is the last hop on the path of 904 the incoming packet, that is between the HA and the Top Level 905 Mobile Router (TLMR) of the Mobile Network. The HA saves the IP 906 address of the TLMR from the source field in the IP header. 908 The rest of the path to the MN is found in the RRH. 910 The sequence counter semantics is changed as described in Section 911 4.2 913 This draft extends [10] section 10.5 as follows: 915 A Home Agent advertises the prefixes of its registered Mobile 916 Routers, during the registration period, on the local Interior 917 Gateway Protocol (IGP). 919 The Routing Header type 2 is extended to be multi-hop. 921 The Home Agent is extended to support routes to prefixes that are 922 owned by Mobile Routers. This can be configured statically, or can 923 be exchanged using a routing protocol as in [12], which is out of the 924 scope of this document. As a consequence of this process, the Home 925 Agent which is selected by a Mobile Router advertises reachability of 926 the MR prefixes for the duration of the registration over the local 927 IGP. 929 When a HA gets a packet for which the destination is a node behind a 930 Mobile Router, it places the packet in the tunnel to the associated 931 MR. This ends up with a packet which destination address in the IP 932 Header is the TLMR, and with a Routing Header of type 2 for the rest 933 of the way to the Mobile Router, which may be multi-hop. 935 To build the RH type 2 from the RRH, the HA sets the type to 2, and 936 clears the bits 32-63 (byte 4 to 7). 938 9. Mobile Router Operation 940 This section inherits from chapter 11 of [10], which is extended to 941 support Mobile Networks and Mobile Routers as a specific case of 942 Mobile Node. 944 This draft extends section 11.2.1 of MIPv6 [10] as follows: 946 o When not at home, an MR uses a reverse tunnel with its HA for all 947 the traffic that is sourced in its mobile network(s); traffic 948 originated further down a nested network is not tunneled twice but 949 for exception cases. 951 o The full path to and within the Mobile Network is piggy-backed 952 with the traffic on a per-packet basis to cope with rapid 953 movement. This makes the packet construction different from 954 MIPv6. 956 The MR when not at home sets up a bi-directional tunnel with its HA. 957 The reverse direction MR -> HA is needed to assure transparent 958 topological correctness to LFNs, as in [12]. But, as opposed to the 959 NEMO Basic Support, nested tunnels are generally avoided. 961 9.1 Processing of ICMP "RRH too small" 963 The New ICMP message "RRH too Small" is presented in Section 5. This 964 message is addressed to the MR which performs the tunnel 965 encapsulation and generates the RRH. 967 Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate 968 it to the originating LFN or inner tunnel source, but MUST process it 969 for itself. 971 If the Current Size in the ICMP messages matches the actual current 972 number of slots in RRH, and if the ICMP passes some safety checks as 973 described in Section 5, then the MR MAY adapt the number of slots to 974 the Proposed Size. 976 9.2 Processing of ICMP error 978 ICMP back { 980 if RRH is present { 981 compute RH type 2 based on RRH 982 get packet source from IP header 983 send ICMP error to source including RH type 2. 984 } 985 else { 986 get packet source from IP header 987 send ICMP error to source with no RH. 988 } 989 } 991 When the MR receives an ICMP error message, it checks whether it is 992 the final destination of the packet by looking at the included 993 packet. If the included packet has an RRH, then the MR will use the 994 RRH to forward the ICMP to the original source of the packet. 996 9.3 Processing of RHH for Outbound Packets 998 The forwarding of a packet with a non saturated RRH consists in fact 999 in passing the hot potato to the attachment router, which does not 1000 require the MRHA tunnel to be up. 1002 So, it happens as soon as a MR has selected its attachment router and 1003 before the binding flow has actually taken place. Also, this process 1004 is much safer since the packet is not forwarded home. 1006 if no RRH in outer header /* First Mobile Router specific */ 1007 or RRH present but saturated { /* Need a nested encapsulation */ 1009 if RRH is saturated { 1010 do ICMP back (RRH too small) 1011 } 1013 /* put packet in sliding reverse tunnel if bound */ 1014 if reverse tunnel is established { 1015 insert new IP header plus RRH 1016 set source address to the MR Home Address 1017 set destination address to the MR Home Agent Address 1018 add an RRH with all slots zeroed out 1019 compute IPsec AH on the resulting packet 1020 } else return 1021 } 1023 /* All MRs including first, even if not bound home */ 1024 if packet size <= MTU { 1025 select first free slot in RRH bottom up 1026 set it to source address from IP header 1027 overwrite source address in IP header with MR CareOf 1028 transmit packet 1029 } else { 1030 do ICMP back (Packet too Big) 1031 } 1033 If the packet already contains an RRH in the outer header, and has a 1034 spare slot, the MR adds the source address from the packet IP header 1035 to the RRH and overwrites the source address in the IP header with 1036 its CoA. As a result, the packets are always topologically correct. 1038 Else, if the RRH is present but is saturated, and therefore the 1039 source IP can not be added, the MR sends a ICMP 'RRH too small' to 1040 the tunnel endpoint which originated the outer packet, using the RRH 1041 info to route it back. The ICMP message is a warning, and the packet 1042 is not discarded. Rather, the MR does a nested encapsulation of the 1043 packet in its own reverse tunnel home with an additional RRH. 1045 Else, if the packet does not have an RRH, the MR puts it in its 1046 reverse tunnel, sourced at the CoA, with an RRH indicating in slot 0 1047 the Home Address of the MR, and with proper IPsec AH as described 1048 further in Section 11.1. 1050 9.4 Processing of the extended Routing Header Type 2 1052 if Segments Left = 0 { 1053 /* new check: packet must be looped back internally */ 1054 if packet doesn't come from a loopback interface { 1055 discard the packet 1056 return 1057 } 1059 proceed to process the next header in the packet, whose type is 1060 identified by the Next Header field in the Routing header 1061 } 1062 else if Hdr Ext Len is odd { 1063 send an ICMP Parameter Problem, Code 0, message to the Source 1064 Address, pointing to the Hdr Ext Len field, and discard the 1065 packet 1066 } 1067 else { 1068 compute n, the number of addresses in the Routing header, by 1069 dividing Hdr Ext Len by 2 1071 if Segments Left is greater than n { 1072 send an ICMP Parameter Problem, Code 0, message to the Source 1073 Address, pointing to the Segments Left field, and discard the 1074 packet 1075 } 1076 else { 1077 decrement Segments Left by 1; 1079 compute i, the index of the next address to be visited in 1080 the address vector, by subtracting Segments Left from n 1082 if Address [i] or the IPv6 Destination Address is multicast { 1083 discard the packet 1084 } 1085 else { 1086 /* new security check */ 1087 if Address [i] doesn't belong to one of the Mobile Network prefixes { 1088 discard the packet 1089 return 1090 } 1092 /* new check: keep MIPv6 behavior: prevent packets from being 1093 * forwarded outside the node. 1094 */ 1095 if Segments Left equals 0 and Address[i] isn't the node's own 1096 home address { 1097 discard the packet 1098 return 1099 } 1100 swap the IPv6 Destination Address and Address[i] 1101 if the IPv6 Hop Limit is less than or equal to 1 { 1102 send an ICMP Time Exceeded -- Hop Limit Exceeded in 1103 Transit message to the Source Address and discard the 1104 packet 1105 } 1106 else { 1107 decrement the Hop Limit by 1 1108 resubmit the packet to the IPv6 module for transmission 1109 to the new destination; 1110 } 1111 } 1112 } 1113 } 1115 9.5 Decapsulation 1117 A MR when decapsulating a packet from its HA must perform the 1118 following checks 1120 1. Destination address 1122 The destination address of the inner packet must belong to one of 1123 the Mobile Network prefixes. 1125 10. Mobile Host Operation 1127 When it is at Home, a Mobile Host issues packets with source set to 1128 its home address and with destination set to its CN, in a plain IPv6 1129 format. 1131 When a MH is not at home but is attached to a foreign link in the 1132 Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to 1133 manage its mobility. 1135 When a MH is visiting a foreign Mobile Network, it forwards its 1136 outbound packets over the reverse tunnel (including RRH) to its HA. 1137 One can view that operation as a first MR process applied on a plain 1138 IPv6 packet issued by a LFN. 1140 As a result, the encapsulating header include: 1142 with source set to the MH COA and destination set to the MH HA 1144 with slot 0 set to the MH Home Address 1146 The inner packet is the plain IPv6 packet from the MH Home Address to 1147 the CN. 1149 11. Security Considerations 1151 This section is not complete; further work is needed to analyze and 1152 solve the security problems of record and source route. 1154 Compared to MIPv6, the main security problem seems to be the fact 1155 that the RRH can be modified in transit by an attacker on the path. 1156 It has to be noted that such an attacker (for example any MR in the 1157 Mobile Network) can perform more effective attacks than modifying the 1158 RRH. 1160 11.1 IPsec Processing 1162 The IPsec [2] AH [3] and ESP [4] can be used in tunnel mode to 1163 provide different security services to the tunnel between a MR and 1164 its HA. ESP tunnel mode SHOULD be used to provide confidentiality 1165 and authentication to the inner packet. AH tunnel mode MUST be used 1166 to provide authentication of the outer IP header fields, especially 1167 the Routing Headers. 1169 11.1.1 Routing Header type 2 1171 Due to the possible usage of Doors [15] to enable IPv4 traversal, the 1172 Routing Header type 2 cannot be treated as type 0 for the purpose of 1173 IPsec processing (i.e. it cannot be included in its intirety in the 1174 Integrity Check Value (ICV) computation, because NAT/PAT may mangle 1175 one of the MR care-of-addresses along the HA-MR path. 1177 The sender (the HA) will put the slot 0 entry (the MR Home Address) 1178 of the RH as destination of the outer packet, will zero out 1179 completely the Routing Header and will perform the ICV computation. 1181 The receiver (the MR) will put the slot 0 entry as destination of the 1182 outer packet, will zero out the Routing Header and will perform the 1183 ICV validation. 1185 11.1.2 Routing Header type 4 1187 The Routing Header type 4 is "partially mutable", and as such can be 1188 included in the Authentication Data calculation. Given the way type 1189 4 is processed, the sender cannot order the field so that it appears 1190 as it will at the receiver; this means the receiver will have to 1191 shuffle the fields. 1193 The sender (the MR) will zero out all the slots and the Segment Used 1194 field of the RRH, and will put as source address of the outer packet 1195 its Home Address, and then will perform the ICV computation. 1197 The receiver (the HA) will put the entry in slot 0 (the MR Home 1198 Address) in the source address and will zero out all the slots and 1199 the Segment Used field of the RRH, and then will perform the ICV 1200 verification. 1202 11.2 New Threats 1204 The RH type 4 is used to construct a MIPv6 RH type 2 with additional 1205 semantics, as described in Section 4.1. Since RH type 2 becomes a 1206 multi hop option like RH type 0, care must be applied to avoid the 1207 spoofing attack that can be performed with the IPv4 source route 1208 option. This is why IPv6 [5] takes special care in responding to 1209 packets carrying Routing Headers. 1211 AH authenticates the MR Home Address identity and the RRH sequence 1212 number. The RRH sequence number is to be used to check the freshness 1213 of the RRH; anti-replay protection can be obtained if the receiver 1214 enables the anti-replay service of AH [3]. 1216 In particular, if IPSec is being used, the content is protected and 1217 can not be read or modified, so there is no point in redirecting the 1218 traffic just to screen it. 1220 Say a MR in a nested structure modifies the RRH in order to bomb a 1221 target outside of the tree. If that MR forwards the packet with 1222 itself as source address, the MR above it will make sure that the 1223 response packets come back to the attacker first, since that source 1224 is prepended to the RRH. If it forges the source address, then the 1225 ingress filtering at the MR above it should detect the irregularity 1226 and drop the packet. Same if the attacker is actually TLMR. The 1227 conclusion is that ingress filtering is recommended at MR and AR. 1229 Say that an attacker in the infrastructure and on the path of the 1230 MRHA tunnel modifies the RRH in order to redirect the response 1231 packets and bomb a target. Considering the position of the attacker 1232 - a compromised access or core router - there's a lot more it could 1233 do to send perturbations to the traffic, like changing source and 1234 destinations of packets on the fly or eventually pollute the routing 1235 protocols. 1237 Say a MR in a nested structure modifies the RH 2 in order to attack a 1238 target outside of the tree. The RH type 2 forwarding rules make sure 1239 that the packet can only go down a tree. So unless the attacker is 1240 TLMR, the packet will not be forwarded. In any case, the attacker 1241 will be bombed first. 1243 Say that an attacker on the path of the MRHA tunnel modifies the RRH 1244 in order to black out the MR. The result could actually be 1245 accomplished by changing any bit in the packet since the IPSec 1246 signature would fail, or scrambling the radio waves in the case of 1247 wireless. 1249 Selecting the tree to attach to is a security critical operation 1250 outside of the scope of this draft. Note that the MR should not 1251 select a path based on trust but rather on measured service. If a 1252 better bandwidth is obtained via an untrusted access using IPSec, 1253 isn't it better than a good willing low bandwidth trusted access? 1255 12. Protocol Constants 1257 DEF_RRH_SLOTS: 7 1259 MAX_RRH_SLOTS: 10 1261 13. Acknowledgements 1263 The authors wish to thank David Auerbach, Fred Baker, Dana Blair, 1264 Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur, 1265 Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick 1266 Wetterwald -last but not least :)-. 1268 14 References 1270 [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1271 1981. 1273 [2] Kent, S. and R. Atkinson, "Security Architecture for the 1274 Internet Protocol", RFC 2401, November 1998. 1276 [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1277 November 1998. 1279 [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1280 (ESP)", RFC 2406, November 1998. 1282 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1283 Specification", RFC 2460, December 1998. 1285 [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1286 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1288 [7] Conta, A. and S. Deering, "Internet Control Message Protocol 1289 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1290 Specification", RFC 2463, December 1998. 1292 [8] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an 1293 On-line Database", RFC 3232, January 2002. 1295 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 1296 3753, June 2004. 1298 [10] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1299 IPv6", RFC 3775, June 2004. 1301 [11] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1302 draft-ietf-nemo-terminology-01 (work in progress), February 1303 2004. 1305 [12] Devarapalli, V., "Network Mobility (NEMO) Basic Support 1306 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 1307 June 2004. 1309 [13] Thubert, P. and N. Montavont, "Nested Nemo Tree Discovery", 1310 draft-thubert-tree-discovery-00 (work in progress), May 2004. 1312 [14] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home 1313 Network models", draft-ietf-nemo-home-network-models-00 (work 1314 in progress), April 2004. 1316 [15] Thubert, P., Molteni, M. and P. Wetterwald, "IPv4 traversal for 1317 MIPv6 based Mobile Routers", 1318 draft-thubert-nemo-ipv4-traversal-01 (work in progress), May 1319 2003. 1321 Authors' Addresses 1323 Pascal Thubert 1324 Cisco Systems Technology Center 1325 Village d'Entreprises Green Side 1326 400, Avenue Roumanille 1327 Biot - Sophia Antipolis 06410 1328 FRANCE 1330 EMail: pthubert@cisco.com 1332 Marco Molteni 1333 Cisco Systems Technology Center 1334 Village d'Entreprises Green Side 1335 400, Avenue Roumanille 1336 Biot - Sophia Antipolis 06410 1337 FRANCE 1339 EMail: mmolteni@cisco.com 1341 Appendix A. Optimizations 1343 A.1 Path Optimization with RRH 1345 The body of the draft presents RRH as a header that circulates in the 1346 reverse tunnel exclusively. The RRH format by itself has no such 1347 limitation. This section illustrates a potential optimization for 1348 end-to-end traffic between a Mobile Network Node and its 1349 Correspondent Node. 1351 The MNN determines that it is part of a Mobile Network by screening 1352 the Tree Information option in the RA messages from its Attachment 1353 Router. In particular, the MNN knows the TreeDepth as advertised by 1354 the AR. An initial test phase could be derived from MIPv6 to decide 1355 whether optimization with a given CN is possible. 1357 When an MNN performs end-to-end optimization with a CN, the MNN 1358 inserts an empty RRH inside its packets, as opposed to tunneling them 1359 home, which is the default behavior of a Mobile Host as described in 1360 Section 10. 1362 The number of slots in the RRH is initially the AR treeDepth plus 1, 1363 but all slots are clear as opposed to the MR process as described in 1364 Section 9. The source address in the header is the MNN address, and 1365 the destination is the CN. 1367 The AR of the MNN is by definition an MR. Since an RRH is already 1368 present in the packet, the MR does not put the packets from the MNN 1369 on its reverse tunnel, but acts as an intermediate MR; it adds the 1370 source address of the packet (the MNN's address) in the RRH (in slot 1371 0) and stamps its careOf instead in the IP header source address 1372 field. Recursively, all the MRs on a nested network trace in path in 1373 the RRH and take over the source IP. 1375 The support required on the CN side extends MIPv6 in a way similar to 1376 the extension that this draft proposes for the HA side. The CN is 1377 required to parse the RRH when it is valid, refresh its BCE 1378 accordingly, and include an RH type 2 with the full path to its 1379 packets to the MNN. 1381 Note that there is no Bind Update between the MNN and the CN. The 1382 RRH must be secured based on tokens exchanged in the test phase. For 1383 the sake of security, it may be necessary to add fields to the RRH or 1384 to add a separate option in the Mobility Header. 1386 A.2 Packet Size Optimization 1388 RRH allows to update the Correspondent BCE on a per packet basis, 1389 which is the highest resolution that we can achieve. While this may 1390 cope with highly mobile and nested configurations, it can also be an 1391 overkill in some situations. 1393 The RRH comes at a cost: it requires processing in all intermediate 1394 Mobile Routers and in the Correspondent Node. Also, a RRH increases 1395 the packet size by more than the size of an IP address per hop in the 1396 Mobile Network. 1398 This is why an additional Routing Header is proposed (type 3). The 1399 semantics of type 3 are very close to type 4 but: 1401 o Type 3 has only one slot, for the Home Address of the source. 1403 o When it can not add the source to the RH type 3 of an outbound 1404 packet, an intermediate MR: 1406 * MR MUST NOT send ICMP (RRH too small) 1408 * MUST NOT put the packet in a reverse tunnel 1410 Rather, it simply overwrites the source and forwards the packet up 1411 the tree as if the RRH had been properly updated. 1413 o Since the path information is not available, the correspondent 1414 MUST NOT update its BCE based on the RH type 3. The CN (or HA) 1415 identifies the source from the entry in slot 0 and may reconstruct 1416 the initial packet using the CareOf in slot 1 as source for AH 1417 purposes. 1419 /* MR processing on outbound packet with RH type 3 support */ 1420 { 1422 if no RH type 3 or 4 in outer header /* First Mobile Router specific */ 1423 or RH type 4 present but saturated { /* Need a nested encapsulation */ 1425 if RRH is saturated { 1426 do ICMP back (RRH too small) 1427 } 1429 /* put packet in sliding reverse tunnel */ 1430 insert new IP header plus RRH 1431 set source address to the MR Home Address 1432 set destination address to the MR Home Agent Address 1433 add an RRH with all slots zeroed out 1434 compute IPsec AH on the resulting packet 1435 } 1437 /* All MRs including first */ 1438 if packet size > MTU { 1439 do ICMP back (Packet too Big) 1440 } else if RRH { 1441 select first free slot in RRH bottom up 1442 set it to source address from IP header 1443 overwrite source address in IP header with MR CareOf 1444 transmit packet 1445 } else if RH type 3 { 1446 if slot 0 is still free { 1447 /* this is end-to-end optimization */ 1448 set it to source address from IP header 1449 } 1450 overwrite source address in IP header with MR CareOf 1451 transmit packet 1452 } 1453 } 1455 A.2.1 Routing Header Type 3 (Home Address option replacement) 1457 This is an RH-based alternative to the Home Address destination 1458 option. Its usage is described in Appendix A.2. 1460 The decision to send RH type 3 or type 4 is up to the source of the 1461 RRH. Several algorithms may apply, one out of N being the simplest. 1463 IPsec HA processing is done as described in Section 11.1 for Type 4. 1465 The Type 3 Routing Header has the following format: 1467 0 1 2 3 1468 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 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Next Header | Hdr Ext Len | Routing Type=3| Segments Used | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Reserved | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | | 1475 + + 1476 | | 1477 + Home Address + 1478 | | 1479 + + 1480 | | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 Next Header 1485 8-bit selector. Identifies the type of header immediately 1486 following the Routing header. Uses the same values as the IPv4 1487 Protocol field [8]. 1489 Hdr Ext Len 1491 8-bit unsigned integer. Length of the Routing header in 8-octet 1492 units, not including the first 8 octets. For the Type 3 Routing 1493 header, Hdr Ext Len is always 2. 1495 Routing Type 1497 8-bit unsigned integer. Set to 3. 1499 Segment Used 1501 8-bit unsigned integer. Number of slots used. Either 0 or 1. 1502 When the field is zero, then there is no MR on the path and it is 1503 valid for a CN that does not support RRH to ignore this header. 1505 Reserved 1507 32-bit reserved field. Initialized to zero for transmission; 1508 ignored on reception. 1510 Home Address 1512 128-bit home address of the source of the packet. 1514 Appendix B. Multi Homing 1516 B.1 Multi-Homed Mobile Network 1518 Consider difference between situation A and B in this diagram: 1520 ===?== ==?=== 1521 MR1 MR2 1522 | | 1523 ==?=====?== ==?====== situation A 1524 MR3 MR4 MR5 1525 | | | 1526 === === === 1528 ===?== ==?=== 1529 MR1 MR2 1530 | | 1531 ==?=====?=======?====== situation B 1532 MR3 MR4 MR5 1533 | | | 1534 === === === 1536 Going from A to B, MR5 may now choose between MR1 and MR2 for its 1537 Attachment (default) Router. In terms of Tree Information, MR5, as 1538 well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once 1539 MR5 selects its AR, MR2, say, MR5 belongs to the associated tree and 1540 whether MR1 can be reached or not makes no difference. 1542 As long as each MR has a single default router for all its outbound 1543 traffic, 2 different logical trees can be mapped over the physical 1544 configurations in both situations, and once the trees are 1545 established, both cases are equivalent for the processing of RRH. 1547 Note that MR5 MUST use a CareOf based on a prefix owned by its AR as 1548 source of the reverse tunnel, even if other prefixes are present on 1549 the Mobile Network, to ensure that a RH type 2 can be securely routed 1550 back. 1552 B.2 Multihomed Mobile Router 1554 Consider the difference between situation B and C in this diagram: 1556 ===?== ==?=== 1557 MR1 MR2 1558 | | 1559 ==?=====?=======?====== situation B 1560 MR3 MR4 MR5 1561 | | | 1562 === === === 1564 ==? ?== 1565 MR1 1566 | 1567 ==?=====?=======?====== situation C 1568 MR3 MR4 MR5 1569 | | | 1570 === === === 1572 In situation C, MR2's egress interface and its properties are 1573 migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home 1574 Agents, and 2 active interfaces. 1576 If MR1 uses both CareOf addresses at a given point of time, and if 1577 they belong to different prefixes to be used via different attachment 1578 routers, then MR1 actually belongs to 2 trees. It must perform some 1579 routing logic to decide whether to forward packets on either egress 1580 interface. Also, it MUST advertise both tree information sets in its 1581 RA messages. 1583 The difference between situations C and B is that when an attached 1584 router (MR5, say) selects a tree and forwards egress packets via MR1, 1585 it can not be sure that MR1 will actually forward the packets over 1586 that tree. If MR5 has selected a given tree for a specific reason, 1587 then a new source route header is needed to enforce that path on MR1. 1589 The other way around, MR5 may leave the decision up to MR1. If MR1 1590 uses the same attachment router for a given flow or at least a given 1591 destination, then the destination receives consistent RRHs. 1592 Otherwise, the BCE cache will flap, but as both paths are valid, the 1593 traffic still makes it through. 1595 Appendix C. Changes from Previous Version of the Draft 1597 From -04 to -05 1599 Tree Information option: now a reference to a separate draft. 1601 Removed RRH heartbeat. 1603 Added a DHAAD section 1605 Clarified how RRH solves the mobile home deadlock. 1607 new section "Optimum number of slots in RRH" from ICMP section 1609 From -03 to -04 1611 TI option: renamed the F (fixed) flag bit to G (grounded). 1613 Binding Update: Made clear that the BU flow conforms MIPv6 and 1614 NEMO but that RRH replaces both Home address Option and Alternate 1615 CareOf option. 1617 From -02 to -03 1619 Reworded the security part to remove an ambiguity that let the 1620 reader think that RRH is unsafe. 1622 From -01 to -02 1624 Made optional the usage of ICMP warning "RRH too small" (Section 1625 5). 1627 Changed the IPsec processing for Routing Header type 2 (Section 1628 11.1). 1630 From -00 to -01 1632 Added new Tree Information Option fields: 1634 A 8 bits Bandwidth indication that provides an idea of the 1635 egress bandwidth. 1637 A CRC-32 that changes with the egress path out of the tree. 1639 a 32 bits unsigned integer, built by each MR out of a high 1640 order configured preference and 24 bits random constant. This 1641 can help as a tie break in Attachment Router selection. 1643 Reduced the 'negative' part of the lollipop space to 0..255 1645 Fixed acknowledgements (sorry Patrick :) 1647 Changed the type of Tree Information Option from 7 to 10. 1649 Intellectual Property Statement 1651 The IETF takes no position regarding the validity or scope of any 1652 Intellectual Property Rights or other rights that might be claimed to 1653 pertain to the implementation or use of the technology described in 1654 this document or the extent to which any license under such rights 1655 might or might not be available; nor does it represent that it has 1656 made any independent effort to identify any such rights. Information 1657 on the procedures with respect to rights in RFC documents can be 1658 found in BCP 78 and BCP 79. 1660 Copies of IPR disclosures made to the IETF Secretariat and any 1661 assurances of licenses to be made available, or the result of an 1662 attempt made to obtain a general license or permission for the use of 1663 such proprietary rights by implementers or users of this 1664 specification can be obtained from the IETF on-line IPR repository at 1665 http://www.ietf.org/ipr. 1667 The IETF invites any interested party to bring to its attention any 1668 copyrights, patents or patent applications, or other proprietary 1669 rights that may cover technology that may be required to implement 1670 this standard. Please address the information to the IETF at 1671 ietf-ipr@ietf.org. 1673 Disclaimer of Validity 1675 This document and the information contained herein are provided on an 1676 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1677 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1678 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1679 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1680 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1681 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1683 Copyright Statement 1685 Copyright (C) The Internet Society (2004). This document is subject 1686 to the rights, licenses and restrictions contained in BCP 78, and 1687 except as set forth therein, the authors retain all their rights. 1689 Acknowledgment 1691 Funding for the RFC Editor function is currently provided by the 1692 Internet Society.