idnits 2.17.1 draft-thubert-nemo-reverse-routing-header-07.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, updated by RFC 4748 on line 1770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1794. 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 669: '...e RH type 0, and the RH type 0 MUST be...' RFC 2119 keyword, line 721: '...slots in the RRH MUST NOT be larger th...' RFC 2119 keyword, line 733: '... slot in the RRH MAY send that ICMP "R...' RFC 2119 keyword, line 737: '...he RRH. The Proposed Size MUST NOT be...' RFC 2119 keyword, line 745: '...stination and it MUST NOT forward it t...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 14, 2007) is 6274 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 613, but not defined == Unused Reference: '5' is defined on line 1368, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1372, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1376, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1380, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-04 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '9') ** Obsolete normative reference: RFC 3775 (ref. '10') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2460 (ref. '13') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '14') ** Obsolete normative reference: RFC 2463 (ref. '15') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (ref. '16') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2401 (ref. '17') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '18') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '19') (Obsoleted by RFC 4303, RFC 4305) Summary: 11 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: August 18, 2007 Cisco Systems 5 February 14, 2007 7 IPv6 Reverse Routing Header and its application to Mobile Networks 8 draft-thubert-nemo-reverse-routing-header-07 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 August 18, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Recursive complexity . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 6 56 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 59 3. An Example . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. New Routing Headers . . . . . . . . . . . . . . . . . . . . . 12 62 4.1. Routing Header Type 2 (MIPv6 RH with extended 63 semantics) . . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.2. Routing Header Type 4 (The Reverse Routing Header) . . . . 14 65 4.3. Extension Header order . . . . . . . . . . . . . . . . . . 17 67 5. Optimum number of slots in RRH . . . . . . . . . . . . . . . . 19 69 6. Reverse Routability test . . . . . . . . . . . . . . . . . . . 21 71 7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . . . 22 72 7.1. Modified Router Advertisement Message Format . . . . . . . 22 74 8. MIPv6 flows . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 8.1. DHAAD . . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 8.2. Binding Updates . . . . . . . . . . . . . . . . . . . . . 23 78 9. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 24 80 10. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 26 81 10.1. Processing of ICMP "RRH too small" . . . . . . . . . . . . 26 82 10.2. Processing of ICMP error . . . . . . . . . . . . . . . . . 27 83 10.3. Processing of RHH for Outbound Packets . . . . . . . . . . 27 84 10.4. Processing of the extended Routing Header Type 2 . . . . . 28 85 10.5. Decapsulation . . . . . . . . . . . . . . . . . . . . . . 30 87 11. Mobile Host Operation . . . . . . . . . . . . . . . . . . . . 31 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 90 12.1. IPsec Processing . . . . . . . . . . . . . . . . . . . . . 32 91 12.1.1. Routing Header type 2 . . . . . . . . . . . . . . . . 32 92 12.1.2. Routing Header type 4 . . . . . . . . . . . . . . . . 32 93 12.2. New Threats . . . . . . . . . . . . . . . . . . . . . . . 34 95 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 36 97 14. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 37 99 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 101 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 102 16.1. informative reference . . . . . . . . . . . . . . . . . . 39 103 16.2. normative reference . . . . . . . . . . . . . . . . . . . 39 105 Appendix A. Optimizations . . . . . . . . . . . . . . . . . . . . 41 106 A.1. Path Optimization with RRH . . . . . . . . . . . . . . . . 41 107 A.2. Packet Size Optimization . . . . . . . . . . . . . . . . . 42 108 A.2.1. Routing Header Type 3 (Home Address option 109 replacement) . . . . . . . . . . . . . . . . . . . . 43 111 Appendix B. Multi Homing . . . . . . . . . . . . . . . . . . . . 46 112 B.1. Multi-Homed Mobile Network . . . . . . . . . . . . . . . . 46 113 B.2. Multihomed Mobile Router . . . . . . . . . . . . . . . . . 47 115 Appendix C. Changes from Previous Version of the Draft . . . . . 48 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 118 Intellectual Property and Copyright Statements . . . . . . . . . . 51 120 1. Introduction 122 This document assumes that the reader is familiar with the Mobile 123 Networks terminology defined in [9] and [1], with Mobile IPv6 defined 124 in [10], and with the NEMO basic support defined in [11]. 126 Generally a Mobile Network may be either solid (a network with one 127 mobile router) or nested, single or multi-homed. This proposal 128 starts from the assumption that nested Mobile Networks will be the 129 norm, and so presents a solution that avoids the tunnel within tunnel 130 overhead of already existing proposals. 132 The solution is based on a single, telescopic tunnel between the 133 first Mobile Router (MR) to forward a packet and its Home Agent (HA). 134 By using IPsec ESP on that tunnel, home equivalent privacy is 135 obtained without further encapsulation. 137 The solution introduces a new Routing Header (RH), called the Reverse 138 Routing Header (RRH), to perform source routing within the mobile 139 structure. RRH is a variant of IPv4 Loose Source and Record Route 140 (LSRR) [12] adapted for IPv6. RRH records the route out of the 141 nested Mobile Network and can be trivially converted into a routing 142 header for packets destined to the Mobile Network. 144 This version focuses on single-homed Mobile Networks. Hints for 145 further optimizations and multi-homing are given in the appendixes. 147 Local Fixed Node (LFN) and Correspondent Node (CN) operations are 148 left unchanged from Mobile IPv6 [10]. Specifically the CN can also 149 be a LFN. 151 Section 3 proposes an example to illustrate the operation of the 152 proposed solution, leaving detailed specifications to the remaining 153 chapters. The reader may refer to Section 2.1 for the specific 154 terminology. 156 1.1. Recursive complexity 158 A number of drafts and publications suggest -or can be extended to- a 159 model where the Home Agent and any arbitrary Correspondent would 160 actually get individual binding from the chain of nested Mobile 161 Routers, and form a routing header appropriately. 163 An intermediate MR would keep track of all the pending communications 164 between hosts in its subtree of Mobile Networks and their CNs, and a 165 binding message to each CN each time it changes its point of 166 attachment. 168 If this was done, then each CN, by receiving all the binding messages 169 and processing them recursively, could infer a partial topology of 170 the nested Mobile Network, sufficient to build a multi-hop routing 171 header for packets sent to nodes inside the nested Mobile Network. 173 However, this extension has a cost: 175 1. Binding Update storm 177 when one MR changes its point of attachment, it needs to send a 178 BU to all the CNs of each node behind him. When the Mobile 179 Network is nested, the number of nodes and relative CNs can be 180 huge, leading to congestions and drops. 182 2. Protocol Hacks 184 Also, in order to send the BUs, the MR has to keep track of all 185 the traffic it forwards to maintain his list of CNs. In case of 186 IPSec tunneled traffic, that CN information may not be available. 188 3. CN operation 190 The computation burden of the CN becomes heavy, because it has to 191 analyze each BU in a recursive fashion in order to infer nested 192 Mobile Network topology required to build a multi hop routing 193 header. 195 4. Missing BU 197 If a CN doesn't receive the full set of PSBU sent by the MR, it 198 will not be able to infer the full path to a node inside the 199 nested Mobile Network. The RH will be incomplete and the packet 200 may or may not be delivered. 202 5. Obsolete BU 204 If the Binding messages are sent asynchronously by each MR, then, 205 when the relative position of MRs and/or the TLMR point of 206 attachment change rapidly, the image of Mobile Network that the 207 CN maintains is highly unstable. If only one BU in the chain is 208 obsolete due to the movement of an intermediate MR, the 209 connectivity may be lost. 211 A conclusion is that the path information must be somehow aggregated 212 to provide the CN with consistent snapshots of the full path across 213 the Mobile Network. This can be achieved by an IPv6 form of loose 214 source / record route header, that we introduce here as a Reverse 215 Routing Header 217 2. Terminology and Assumptions 219 2.1. Terminology 221 This document assumes that the reader is familiar with Mobile IPv6 as 222 defined in [10] and with the concept of Mobile Router defined in the 223 NEMO terminology document [1]. In particular, the "Nested Mobility 224 Terms" introduced in the NEMO terminology are repeatedly used in this 225 document. 227 Solid Mobile Network: 229 One or more IP subnets attached to a MR and mobile as a unit, with 230 respect to the rest of the Internet. A Solid Mobile Network can 231 be either singly or multi-homed. A Solid Mobile Network may be 232 composed of more then one link and may interconnect several 233 routers, but all routers in the Solid Mobile Network are fixed 234 with respect to each other. 236 We like to represent a simple single-homed Mobile Network as an 237 hanger, because it has only one uplink hook and a bar to which 238 multiple hooks can be attached. Graphically we use the question 239 mark "?" to show the uplink hook (interface) connected to the MR, 240 and the "=" sign to represent the bar: 242 ? 243 MR1 244 | 245 =============== 247 IPv6 Mobile Host: 249 A IPv6 Host, with support for MIPv6 MN, and the additional NEMO 250 capability described in this draft. 252 Home prefix 254 Network prefix, which identifies the home link within the Internet 255 topology. 257 Mobile Network prefix 259 Network prefix, common to all IP addresses in the Mobile Network 260 when the MR is attached to the home link. It may or may not be a 261 subset of the Home subnet prefix. 263 Inbound direction: 265 direction from outside the Mobile Network to inside 267 Outbound direction: 269 direction from inside the Mobile Network to outside 271 RRH: 273 Reverse Routing Header, defined in this specification 275 NULL RRH: 277 A NULL RRH is an RRH with a null "Segments Used" field 279 2.2. Assumptions 281 We make the following assumptions: 283 1. A MR has one Home Agent and one Home Address -> one primary CoA. 285 2. A MR attaches to a single Attachment Router as default router. 287 3. A MR may have more than one uplink interface. 289 4. An interface can be either wired or wireless. The text assumes 290 that interfaces are wireless for generality. 292 5. Each Solid Mobile Network may have more that one L2 Access Point, 293 all of them controlled by the same Attachment Router, which we 294 assume to be the Mobile Router. 296 Since an MR has only one primary CoA, only one uplink interface can 297 be used at a given point of time. Since the MR attaches to a single 298 attachment router, if due care is applied to avoid loops, then the 299 resulting topology is a tree. 301 3. An Example 303 The nested Mobile Network in the following figure has a tree 304 topology, according to the assumptions in Section 2.2. In the tree 305 each node is a Solid Mobile Network, represented by its MR. 307 +---------------------+ 308 | Internet |---CN 309 +---------------|-----+ 310 / Access Router 311 MR3_HA | 312 ======?====== 313 MR1 314 | 315 ====?=============?==============?=== 316 MR5 MR2 MR6 317 | | | 318 =========== ===?========= ============= 319 MR3 320 | 321 ==|=========?== <-- Mobile Network3 322 LFN1 MR4 323 | 324 ========= 326 An example nested Mobile Network 328 This example focuses on a Mobile Network node at depth 3 (Mobile 329 Network3) inside the tree, represented by its mobile router MR3. The 330 path to the Top Level Mobile Router (TLMR) MR1 and then the Internet 331 is 333 MR3 -> MR2 -> MR1 -> Internet 335 Consider the case where a LFN belonging to Mobile Network3 sends a 336 packet to a CN in the Internet, and the CN replies back. With the 337 tunnel within tunnel approach described by [11], we would have three 338 bi-directional nested tunnels: 340 -----------. 341 --------/ /-----------. 342 -------/ | | /-------- 343 CN ------( - - | - - - | - - - | - - - | - - (----- LFN 344 MR3_HA -------\ | | \-------- MR3 345 MR2_HA --------\ \----------- MR2 346 MR1_HA ----------- MR1 348 Depending on the relative location of MR1_HA, MR2_HA and MR3_HA, this 349 may lead to a very inefficient "pinball" routing in the 350 Infrastructure. 352 On the other hand, with the RRH approach we would have only one bi- 353 directional tunnel: 355 --------------------------- MR1 ---- MR2 ---- MR3 356 CN ------( - - - - - - - - - - - - - - (------- LFN 357 MR3_HA --------------------------- MR1 ---- MR2 ---- MR3 359 The first mobile router on the path, MR3, in addition to tunneling 360 the packet to its HA, adds a reverse routing header with N = 3 pre- 361 allocated slots. Choosing the right value for N is discussed in 362 Section 5. The bottom slot is equivalent to the MIPv6 Home Address 363 option. MR3 inserts its home address MR3_HoA into slot 0. 365 The outer packet has source MR3's Care of Address, MR3_CoA, and 366 destination MR3's Home Agent, MR3_HA: 368 <-------------- outer IPv6 header --------------------> 369 +-------+-------++ -- ++----+-------+-------+---------+ +------- 370 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 371 |MR3_CoA|MR3_HA |:oEXT:|type| | |MR3_HoA | |iPACKET 372 | | |: :| 4 | | | | | 373 +-------+-------++ -- ++----+-------+-------+---------+ +------- 375 The second router on the path, MR2, notices that the packet already 376 contains an RRH, and so it overwrites the source address of the 377 packet with its own address, MR2_CoA, putting the old source address, 378 MR3_CoA, in the first free slot of the RRH. 380 The outer packet now has source MR2_CoA and destination MR3_HA; the 381 RRH from top to bottom is MR3_CoA | MR3_HoA: 383 <-------------- outer IPv6 header --------------------> 384 +-------+-------++ -- ++----+-------+-------+---------+ +------- 385 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 386 |MR2_CoA|MR3_HA |:oEXT:|type| |MR3_CoA|MR3_HoA | |iPACKET 387 | | |: :| 4 | | | | | 388 +-------+-------++ -- ++----+-------+-------+---------+ +------- 389 In general the process followed by the second router is repeated by 390 all the routers on the path, including the TLMR (in this example 391 MR1). When the packet leaves MR1 the source address is MR1_CoA and 392 the RRH is MR2_CoA | MR3_CoA | MR3_HoA: 394 <-------------- outer IPv6 header --------------------> 395 +-------+-------++ -- ++----+-------+-------+---------+ +------- 396 |oSRC |oDST |: :|oRRH| slot2 | slot1 | slot0 | | 397 |MR1_CoA|MR3_HA |:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET 398 | | |: :| 4 | | | | | 399 +-------+-------++ -- ++----+-------+-------+---------+ +------- 401 In a colloquial way we may say that while the packet travels from MR3 402 to MR3_HA, the Mobile Network tunnel end point "telescopes" from MR3 403 to MR2 to MR1. 405 When the home agent MR3_HA receives the packet it notices that it 406 contains a RRH and it looks at the bottom entry, MR3_HoA. This entry 407 is used as if it were a MIPv6 Home Address destination option, i.e. 408 as an index into the Binding Cache. When decapsulating the inner 409 packet the home agent performs the checks described in Section 9, and 410 if successful it forwards the inner packet to CN. 412 MR3_HA stores two items in the Bind Cache Entry associated with MR3: 413 the address entries from RRH, to be used to build the RH, and the 414 packet source address MR1_CoA, to be used as the first hop. 416 Further packets from the CN to the LFN are plain IPv6 packets. 417 Destination is LFN, and so the packet reaches MR3's home network. 419 MR3_HA intercepts it, does a Bind Cache prefix lookup and obtains as 420 match the MR3 entry, containing the first hop and the information 421 required to build the RH. It then puts the packet in the tunnel 422 MR3_HA -- MR3 as follows: source address MR3_HA and destination 423 address the first hop, MR1_CoA. The RH is trivially built out of the 424 previous RRH: MR2_CoA | MR3_CoA | MR3_HoA: 426 <-------------- outer IPv6 header --------------------> 427 +-------+-------++ -- ++----+-------+-------+---------+ +------- 428 |oSRC |oDST |: :|oRH | | | | | 429 |MR3_HA |MR1_CoA|:oEXT:|type|MR2_CoA|MR3_CoA|MR3_HoA | |iPACKET 430 | | |: :| 2 | | | | | 431 +-------+-------++ -- ++----+-------+-------+---------+ +------- 432 The packet is routed with plain IP routing up to the first 433 destination MR1_CoA. 435 The RH of the outer packet is type 2 as in MIPv6 [10], but has 436 additional semantics inherited from type 0: it contains the path 437 information to traverse the nested Mobile Network from the TLMR to 438 the tunnel endpoint MR3. Each intermediate destination forwards the 439 packet to the following destination in the routing header. The 440 security aspects of this are treated in Section 12.2. 442 MR1, which is the initial destination in the IP header, looks at the 443 RH and processes it according to Section 10, updating the RH and the 444 destination and sending it to MR2_CoA. MR2 does the same and so on 445 until the packet reaches the tunnel endpoint, MR3. 447 When the packet reaches MR3, the source address in the IP header is 448 MR3_HA, the destination is MR3_CoA and in the RH there is one segment 449 left, MR3_HoA. As a consequence the packet belongs to the MR3_HA -- 450 MR3 tunnel. MR3 decapsulates the inner packet, applying the rules 451 described in Section 10 and sends it to LFN. The packet that reaches 452 LFN is the plain IPv6 packet that was sent by CN. 454 4. New Routing Headers 456 This draft modifies the MIPv6 Routing Header type 2 and introduces 457 two new Routing Headers, type 3 and 4. Type 3, which is an 458 optimization of type 4 will be discussed in Appendix A.2.1. The 459 draft presents their operation in the context of Mobile Routers 460 although the formats are not tied to Mobile IP and could be used in 461 other situations. 463 4.1. Routing Header Type 2 (MIPv6 RH with extended semantics) 465 Mobile IPv6 uses a Routing header to carry the Home Address for 466 packets sent from a Correspondent Node to a Mobile Node. In [10], 467 this Routing header (Type 2) is restricted to carry only one IPv6 468 address. The format proposed here extends the Routing Header type 2 469 to be multi-hop. 471 The processing of the multi-hop RH type 2 inherits from the RH type 0 472 described in IPv6 [13]. Specifically: the restriction on multicast 473 addresses is the same; a RH type 2 is not examined or processed until 474 it reaches the node identified in the Destination Address field of 475 the IPv6 header; in that node, the RH type 0 algorithm applies, with 476 added security checks. 478 The construction of the multi-hop RH type 2 by the HA is described in 479 Section 9; the processing by the MRs is described in Section 10.4; 480 and the security aspects are treated in Section 12.2. 482 The destination node of a packet containing a RH type 2 can be a MR 483 or some other kind of node. If it is a MR it will perform the 484 algorithm described in Section 10.4, otherwise it will operate as 485 prescribed by IPv6 [13] when the routing type is unrecognized. 487 The multi-hop Routing Header type 2, as extended by this draft, has 488 the following format: 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Next Header | Hdr Ext Len | Routing Type=2| Segments Left | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Reserved | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 + + 499 | | 500 + Address[1] + 501 | | 502 + + 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | | 506 + + 507 | | 508 + Address[2] + 509 | | 510 + + 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 . . . 514 . . . 515 . . . 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | | 518 + + 519 | | 520 + Address[n] + 521 | | 522 + + 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Next Header 528 8-bit selector. Identifies the type of header immediately 529 following the Routing header. Uses the same values as the IPv4 530 Protocol field [14]. 532 Hdr Ext Len 534 8-bit unsigned integer. Length of the Routing header in 8-octet 535 units, not including the first 8 octets. For the Type 2 Routing 536 header, Hdr Ext Len is equal to two times the number of addresses 537 in the header. 539 Routing Type 541 8-bit unsigned integer. Set to 2. 543 Segments Left 545 8-bit unsigned integer. Number of route segments remaining, i.e., 546 number of explicitly listed intermediate nodes still to be visited 547 before reaching the final destination. 549 Reserved 551 32-bit reserved field. Initialized to zero for transmission; 552 ignored on reception. 554 Address[1..n] 556 Vector of 128-bit addresses, numbered 1 to n. 558 4.2. Routing Header Type 4 (The Reverse Routing Header) 560 The Routing Header type 4, or Reverse Routing Header (RRH), is a 561 variant of IPv4 loose source and record route (LSRR) [12] adapted for 562 IPv6. 564 Addresses are added from bottom to top (0 to n-1 in the picture). 565 The RRH is designed to help the destination build an RH for the 566 return path. 568 When a RRH is present in a packet, the rule for upper-layer checksum 569 computing is that the source address used in the pseudo-header is 570 that of the original source, located in the slot 0 of the RRH, unless 571 the RRH slot 0 is empty, in which case the source in the IP header of 572 the packet is used. 574 As the 'segment left' field of the generic RH is reassigned to the 575 number of segments used, an IPv6 node that does not support RRH will 576 discard the packet, unless the RRH is empty. 578 The RRH contains n pre-allocated address slots, to be filled by each 579 MR in the path. It is possible to optimize the number of slots using 580 the Tree Information Option described in Section 5. 582 The Type 4 Routing Header has the following format: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Next Header | Hdr Ext Len | Routing Type=4| Segments Used | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Sequence Number | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | | 592 + + 593 | | 594 + Slot[n-1] + 595 | | 596 + + 597 | | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 . . . 600 . . . 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | | 603 + + 604 | | 605 + Slot[1] (1st MR CoA) + 606 | | 607 + + 608 | | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 + + 612 | | 613 + Slot[0] (Home address) + 614 | | 615 + + 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Next Header 621 8-bit selector. Identifies the type of header immediately 622 following the Routing header. Uses the same values as the IPv4 623 Protocol field [14]. 625 Hdr Ext Len 627 8-bit unsigned integer. Length of the Routing header in 8-octet 628 units, not including the first 8 octets. For the Type 4 Routing 629 header, Hdr Ext Len is equal to two times the number of addresses 630 in the header. 632 Routing Type 634 8-bit unsigned integer. Set to 4. 636 Segments Used 638 8-bit unsigned integer. Number of slots used. Initially set to 1 639 by the MR when only the Home Address is there. Incremented by the 640 MRs on the way as they add the packets source addresses to the 641 RRH. 643 Sequence Number 645 32-bit unsigned integer. The Sequence Number starts at 0, and is 646 incremented by the source upon each individual packet. Using the 647 Radia Perlman's lollipop algorithm, values between 0 and 255 are 648 'negative', left to indicate a reboot or the loss of HA 649 connectivity, and are skipped when wrapping and upon positive 650 Binding Ack. The sequence number is used to check the freshness of 651 the RRH; anti-replay protection is left to IPsec AH. 653 Slot[n-1..0] 655 Vector of 128-bit addresses, numbered n-1 to 0. 657 When applied to the NEMO problem, the RRH can be used to update the 658 HA on the actual location of the MR. Only MRs forwarding packets on 659 an egress interface while not at home update it on the fly. 661 A RRH is inserted by the first MR on the Mobile Network outbound 662 path, as part of the reverse tunnel encapsulation; it is removed by 663 the associated HA when the tunneled packet is decapsulated. 665 4.3. Extension Header order 667 The RH type 2 is to be placed as any RH as described in [13] section 668 4.1. If a RH type 0 is present in the packet, then the RH type 2 is 669 placed immediately after the RH type 0, and the RH type 0 MUST be 670 consumed before the RH type 2. 672 RH type 3 and 4 are mutually exclusive. They are to be placed right 673 after the Hop-by-Hop Options header if any, or else right after the 674 IPv6 header. 676 As a result, the order prescribed in section 4.1 of RFC 2460 becomes: 678 IPv6 header 680 Hop-by-Hop Options header 682 Routing header type 3 or 4 684 Destination Options header (note 1) 686 Routing header type 0 688 Routing header type 2 690 Fragment header 692 Authentication header (note 2) 694 Encapsulating Security Payload header (note 2) 696 Destination Options header (note 3) 698 upper-layer header 700 5. Optimum number of slots in RRH 702 If its current Attachment Router conforms to Tree Discovery as 703 specified in [2], a MR knows its current tree depth from the Tree 704 Information Option (RA-TIO). The maximum number of slots needed in 705 the RRH is the same value as the MR's own tree depth (that is the 706 TreeDepth as received from the AR incremented by one). 708 When sending a Binding Update, a MR always reinitializes the number 709 of slots in the RRH to the maximum of DEF_RRH_SLOTS and its tree 710 depth, if the latter is known from a reliable hint such as RA-TIO. 711 The message may have a number of unused (NULL) slots, when it is 712 received by the Home Agent. The HA crops out the extra entries in 713 order to send a RH of type 2 back with its response. The RH type 2 714 in the resulting Binding Ack contains the number of required slots 715 that the MR now uses until it gets a hint that the topology changes 716 or until the next Binding update. 718 In the case of a NULL RRH, the HA does not include a RH 2 at all. 719 This may happen in the process of a DHAAD message (see Section 8.1) 721 The number of slots in the RRH MUST NOT be larger than MAX_RRH_SLOTS. 722 If a MR is deeper in a tree then MAX_RRH_SLOTS, the packets will be 723 reencapsulated by a MR up high in the tree, or dropped, depending on 724 that MR security policy. 726 In runtime, it may happen that the RRH has fewer slots than required 727 for the number of MRs in the path because either the nested Mobile 728 Network topology is changing too quickly, or the MR that inserted the 729 RRH had a wrong representation of the topology. 731 To solve this problem a new ICMP message is introduced, "RRH 732 Warning", type 64. A MR on the tree egress path that gets a packet 733 without a free slot in the RRH MAY send that ICMP "RRH warning" back 734 to the MR that inserted the RRH in the first place. 736 This message allows a MR on the path to propose a larger number of 737 slots to the MR that creates the RRH. The Proposed Size MUST NOT be 738 larger than MAX_RRH_SLOTS. The originating MR must rate-limit the 739 ICMP messages to avoid excessive ICMP traffic in the case of the 740 source failing to operate as requested. 742 The originating MR must insert an RH type 2 based on the RRH in the 743 associated IP header, in order to route the ICMP message back to the 744 source of the reverse tunnel. A MR that receives this ICMP message 745 is the actual destination and it MUST NOT forward it to the (LFN) 746 source of the tunneled packet. 748 The type 64 ICMP has the following format: 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Type = 64 | Code = 0 | Checksum | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Current Size | Proposed Size | Reserved | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | As much of invoking packet | 758 + as will fit without the ICMPv6 packet + 759 | exceeding the minimum IPv6 MTU | 760 . . 761 . . 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Type 766 64 [To Be Assigned] 768 Code 0: RRH too small 770 The originating MR requires the source to set the RRH size to a 771 larger value. The packet that triggered the ICMP will still be 772 forwarded by the MR, but the path cannot be totally optimized (see 773 Section 10.3). 775 Checksum 777 The ICMP checksum [15]. 779 Current Size 781 RRH size of the invoking packet, as a reference. 783 Proposed Size 785 The new value, expressed as a number of IPv6 addresses that can 786 fit in the RRH. 788 Reserved 790 16-bit reserved field. Initialized to zero for transmission; 791 ignored on reception. 793 6. Reverse Routability test 795 Compared to [10], the RRH models presents an opening for an attack 796 against the CoA or any address in the RRH. This risk is discussed in 797 Section 12.2. 799 For deployments where this risk is acceptable, MR and HA can proceed 800 as described further in the draft, and in particular, enable any 801 packet with proper authentication to update the RRH in the Binding 802 Cache Entry. 804 For other deployments, this risk might be unacceptable. This section 805 presents a mechanism that SHOULD be present in all implementations, 806 and configurable as an option in the Home Agent. The mechanism 807 expects that all binding messages are subject to proper 808 authentication 810 The mechanism, when configured, works like this: 812 When a HA receives a BU with a change in either the CoA or any entry 813 in the RRH, it will reject the binding with a status code 135 814 "Sequence number out of window". The HA stores the RRH and the CoA 815 in a transit zone inside the binding cache entry. The HA also forges 816 a new Sequence Counter that it places in the BA as a challenge. 818 Upon the BA with status code 135 "Sequence number out of window", the 819 MR builds a new BU with the resynchronized Sequence Number, and a 820 Routing Header of type 4. 822 Upon receiving a BU that matches the information in the transit zone 823 (same CoA, same RRH, valid sequence), the HA accepts the BU and 824 updates its binding cache entry information as described further in 825 this document. 827 When the mechanism is triggered, the HA does not accept to update its 828 binding cache when a packet indicates a change in the CoA or the RRH, 829 but drops the packet instead. 831 7. Modifications to IPv6 Neighbor Discovery 833 7.1. Modified Router Advertisement Message Format 835 Mobile IPv6 [10] modifies the format of the Router Advertisement 836 message [16] by the addition of a single flag bit (H) to indicate 837 that the router sending the Advertisement message is serving as a 838 home agent on this link. 840 This draft adds another single flag bit (N) to indicate that the 841 router sending the advertisement message is a MR. This means that 842 the link on which the message is sent is a Mobile Network, which may 843 or may not be at home. 845 The Router Advertisement message has the following format: 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type | Code | Checksum | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Reachable Time | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Retrans Timer | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Options ... 859 +-+-+-+-+-+-+-+-+-+-+-+- 861 This format represents the following changes over that originally 862 specified for Neighbor Discovery [16]: 864 Home Agent (H) 866 The Home Agent (H) bit is set in a Router Advertisement to 867 indicate that the router sending this Router Advertisement is also 868 functioning as a Mobile IP home agent on this link. 870 NEMO Capable (N) 872 The NEMO Capable (N) bit is set in a Router Advertisement to 873 indicate that the router sending this Router Advertisement is also 874 functioning as a Mobile Router on this link, so that the link is a 875 Mobile Network, possibly away from home. 877 8. MIPv6 flows 879 8.1. DHAAD 881 Conforming MIPv6 [10], a MR normally does not identify itself in its 882 DHAAD messages, using a Home Address option. For the same reason, a 883 RRH with a Home address in slot 0 is not required here, either. Yet, 884 this specification allows a MR to send its DHAAD messages with a NULL 885 RRH, as opposed to no RRH at all. 887 This is generally useful if the attachment router is not bound yet, 888 for whatever reason, and more specifically in the case of the Mobile 889 Home Network as described in [3]. In the latter case, an HA is 890 mobile and may happen to be located under one of its MRs (within its 891 subtree), which is a dead lock for the NEMO basic support.. 893 Since MRs may forward packets with an RRH even if themselves are not 894 bound yet, the packets from nested MRs can be forwarded and the 895 responses are source routed back, allowing the nested MRs to bind. 896 In particular, if a nested MR is also a mobile Home Agent, it becomes 897 reachable from its own MRs, which breaks the deadlock. 899 Also, this alleviates the need for the attachment router to forward 900 DHAAD messages across its own MRHA tunnel. 902 HAs MUST respond by reversing the RRH into a RH2 if a RRH is present 903 and not NULL. A NULL RRH is ignored. 905 8.2. Binding Updates 907 A MIPv6 or NEMO Binding Update provides more information than just 908 the path in the nested cloud so they are still used as described in 909 MIPv6 [10] for Home Registration and de-registration. The only 910 difference when using a RRH is that the Home Address Destination 911 Option and the alternate CareOf MIP option MUST be omitted. 913 The Binding Update flow is also used to update the optimum size of 914 the RRH, as described in Section 5. 916 The HA MUST save the RRH in its binding cache, either in the original 917 form or in the form of an RH type 2, ready to be added to the tunnel 918 header of the MRHA packets. The RRH format is very close to that of 919 the RH type 2, designed to minimize the process of the transmutation. 921 9. Home Agent Operation 923 This section inherits from chapter 10 of MIPv6 [10], which is kept 924 unmodified except for parts 10.5 and 10.6 which are extended. This 925 draft mostly adds the opportunity for a MN to update the Binding 926 Cache of its Home Agent using RRH, though it does not change the fact 927 that MNs still need to select a home agent, register and deregister 928 to it, using the MIP Bind Update. 930 This draft extends [10] section 10.6 as follows: 932 o The entry point of the tunnel is now checked against the TLMR as 933 opposed to the primary CoA. 935 o The Binding Cache can be updated based on RRH with proper AH/ESP 936 authentication. 938 As further explained in Section 8.2, this specification modifies MIP 939 so that the HA can rely on the RH type 4 (RRH) to update its Bind 940 Cache Entry (BCE), when the Mobile Node moves. The conceptual 941 content of the BCE is extended to contain a sequence counter, and the 942 sequence of hops within the --potentially nested-- Mobile Network to 943 a given Mobile Node. The sequence counter is initially set to 0. 945 When the HA receives a packet destined to itself, it checks for the 946 presence of a Routing Header of type 3 or 4. Both contain as least 947 the entry for the home address of the MN in slot 0; this replaces the 948 MIP Home Address Option and allows the HA to determine the actual 949 source of the packet, to access the corresponding security 950 association. 952 As explained in Section 12.2, the HA MUST verify the authenticity of 953 the packet using IPSEC AH and drop packets that were not issued by 954 the proper Mobile Node. An RRH is considered only if the packet is 955 authenticated and if its sequence number is higher than the one saved 956 in the BCE. 958 Also, an RRH is considered only if an initial Bind Update exchange 959 has been successfully completed between the Mobile Node and its Home 960 Agent for Home Registration. If the RRH is valid, then the Bind 961 Cache Entry is revalidated for a lifetime as configured from the 962 initial Bind Update. 964 The BCE abstract data is updated as follows: 966 The first hop for the return path is the last hop on the path of 967 the incoming packet, that is between the HA and the Top Level 968 Mobile Router (TLMR) of the Mobile Network. The HA saves the IP 969 address of the TLMR from the source field in the IP header. 971 The rest of the path to the MN is found in the RRH. 973 The sequence counter semantics is changed as described in 974 Section 4.2 976 reverse Routability test transit zone: a candidate RRH and a 977 challenge sequence counter. 979 This draft extends [10] section 10.5 as follows: 981 A Home Agent advertises the prefixes of its registered Mobile 982 Routers, during the registration period, on the local Interior 983 Gateway Protocol (IGP). 985 The Routing Header type 2 is extended to be multi-hop. 987 The Home Agent is extended to support routes to prefixes that are 988 owned by Mobile Routers. This can be configured statically, or can 989 be exchanged using a routing protocol as in [11], which is out of the 990 scope of this document. As a consequence of this process, the Home 991 Agent which is selected by a Mobile Router advertises reachability of 992 the MR prefixes for the duration of the registration over the local 993 IGP. 995 When a HA gets a packet for which the destination is a node behind a 996 Mobile Router, it places the packet in the tunnel to the associated 997 MR. This ends up with a packet which destination address in the IP 998 Header is the TLMR, and with a Routing Header of type 2 for the rest 999 of the way to the Mobile Router, which may be multi-hop. 1001 To build the RH type 2 from the RRH, the HA sets the type to 2, and 1002 clears the bits 32-63 (byte 4 to 7). 1004 10. Mobile Router Operation 1006 This section inherits from chapter 11 of [10], which is extended to 1007 support Mobile Networks and Mobile Routers as a specific case of 1008 Mobile Node. 1010 This draft extends section 11.2.1 of MIPv6 [10] as follows: 1012 o When not at home, an MR uses a reverse tunnel with its HA for all 1013 the traffic that is sourced in its mobile network(s); traffic 1014 originated further down a nested network is not tunneled twice but 1015 for exception cases. 1017 o The full path to and within the Mobile Network is piggy-backed 1018 with the traffic on a per-packet basis to cope with rapid 1019 movement. This makes the packet construction different from 1020 MIPv6. 1022 The MR when not at home sets up a bi-directional tunnel with its HA. 1023 The reverse direction MR -> HA is needed to assure transparent 1024 topological correctness to LFNs, as in [11]. But, as opposed to the 1025 NEMO Basic Support, nested tunnels are generally avoided. 1027 10.1. Processing of ICMP "RRH too small" 1029 The New ICMP message "RRH too Small" is presented in Section 5. This 1030 message is addressed to the MR which performs the tunnel 1031 encapsulation and generates the RRH. 1033 Hence, a MR that receives the ICMP "RRH too small" MUST NOT propagate 1034 it to the originating LFN or inner tunnel source, but MUST process it 1035 for itself. 1037 If the Current Size in the ICMP messages matches the actual current 1038 number of slots in RRH, and if the ICMP passes some safety checks as 1039 described in Section 5, then the MR MAY adapt the number of slots to 1040 the Proposed Size. 1042 10.2. Processing of ICMP error 1044 ICMP back { 1046 if RRH is present { 1047 compute RH type 2 based on RRH 1048 get packet source from IP header 1049 send ICMP error to source including RH type 2. 1050 } 1051 else { 1052 get packet source from IP header 1053 send ICMP error to source with no RH. 1054 } 1055 } 1057 When the MR receives an ICMP error message, it checks whether it is 1058 the final destination of the packet by looking at the included 1059 packet. If the included packet has an RRH, then the MR will use the 1060 RRH to forward the ICMP to the original source of the packet. 1062 10.3. Processing of RHH for Outbound Packets 1064 The forwarding of a packet with a non saturated RRH consists in fact 1065 in passing the hot potato to the attachment router, which does not 1066 require the MRHA tunnel to be up. 1068 So, it happens as soon as a MR has selected its attachment router and 1069 before the binding flow has actually taken place. Also, this process 1070 is much safer since the packet is not forwarded home. 1072 if no RRH in outer header /* First Mobile Router specific */ 1073 or RRH present but saturated { /* Need a nested encapsulation */ 1075 if RRH is saturated { 1076 do ICMP back (RRH too small) 1077 } 1079 /* put packet in sliding reverse tunnel if bound */ 1080 if reverse tunnel is established { 1081 insert new IP header plus RRH 1082 set source address to the MR Home Address 1083 set destination address to the MR Home Agent Address 1084 add an RRH with all slots zeroed out 1085 compute IPsec AH on the resulting packet 1086 } else return 1087 } 1089 /* All MRs including first, even if not bound home */ 1090 if packet size <= MTU { 1091 select first free slot in RRH bottom up 1092 set it to source address from IP header 1093 overwrite source address in IP header with MR CareOf 1094 transmit packet 1095 } else { 1096 do ICMP back (Packet too Big) 1097 } 1099 If the packet already contains an RRH in the outer header, and has a 1100 spare slot, the MR adds the source address from the packet IP header 1101 to the RRH and overwrites the source address in the IP header with 1102 its CoA. As a result, the packets are always topologically correct. 1104 Else, if the RRH is present but is saturated, and therefore the 1105 source IP can not be added, the MR sends a ICMP 'RRH too small' to 1106 the tunnel endpoint which originated the outer packet, using the RRH 1107 info to route it back. The ICMP message is a warning, and the packet 1108 is not discarded. Rather, the MR does a nested encapsulation of the 1109 packet in its own reverse tunnel home with an additional RRH. 1111 Else, if the packet does not have an RRH, the MR puts it in its 1112 reverse tunnel, sourced at the CoA, with an RRH indicating in slot 0 1113 the Home Address of the MR, and with proper IPsec AH as described 1114 further in Section 12.1. 1116 10.4. Processing of the extended Routing Header Type 2 1118 if Segments Left = 0 { 1119 /* new check: packet must be looped back internally */ 1120 if packet doesn't come from a loopback interface { 1121 discard the packet 1122 return 1123 } 1125 proceed to process the next header in the packet, whose type is 1126 identified by the Next Header field in the Routing header 1127 } 1128 else if Hdr Ext Len is odd { 1129 send an ICMP Parameter Problem, Code 0, message to the Source 1130 Address, pointing to the Hdr Ext Len field, and discard the 1131 packet 1132 } 1133 else { 1134 compute n, the number of addresses in the Routing header, by 1135 dividing Hdr Ext Len by 2 1137 if Segments Left is greater than n { 1138 send an ICMP Parameter Problem, Code 0, message to the Source 1139 Address, pointing to the Segments Left field, and discard the 1140 packet 1141 } 1142 else { 1143 decrement Segments Left by 1; 1145 compute i, the index of the next address to be visited in 1146 the address vector, by subtracting Segments Left from n 1148 if Address [i] or the IPv6 Destination Address is multicast { 1149 discard the packet 1150 } 1151 else { 1152 /* new security check */ 1153 if Address [i] doesn't belong to one of the MNP { 1154 discard the packet 1155 return 1156 } 1158 /* new check: keep MIPv6 behavior prevent packets from being 1159 * forwarded outside the node. 1160 */ 1161 if Segments Left is 0 and Address[i] isn't the node's own 1162 home address { 1163 discard the packet 1164 return 1165 } 1166 swap the IPv6 Destination Address and Address[i] 1167 if the IPv6 Hop Limit is less than or equal to 1 { 1168 send an ICMP Time Exceeded -- Hop Limit Exceeded in 1169 Transit message to the Source Address and discard the 1170 packet 1171 } 1172 else { 1173 decrement the Hop Limit by 1 1174 resubmit the packet to the IPv6 module for transmission 1175 to the new destination; 1176 } 1177 } 1178 } 1179 } 1181 10.5. Decapsulation 1183 A MR when decapsulating a packet from its HA must perform the 1184 following checks 1186 1. Destination address 1188 The destination address of the inner packet must belong to one of 1189 the Mobile Network prefixes. 1191 11. Mobile Host Operation 1193 When it is at Home, a Mobile Host issues packets with source set to 1194 its home address and with destination set to its CN, in a plain IPv6 1195 format. 1197 When a MH is not at home but is attached to a foreign link in the 1198 Fixed Infrastructure, it SHOULD use MIPv6 as opposed to this draft to 1199 manage its mobility. 1201 When a MH is visiting a foreign Mobile Network, it forwards its 1202 outbound packets over the reverse tunnel (including RRH) to its HA. 1203 One can view that operation as a first MR process applied on a plain 1204 IPv6 packet issued by a LFN. 1206 As a result, the encapsulating header include: 1208 with source set to the MH COA and destination set to the MH HA 1210 with slot 0 set to the MH Home Address 1212 The inner packet is the plain IPv6 packet from the MH Home Address to 1213 the CN. 1215 12. Security Considerations 1217 This section is not complete; further work is needed to analyze and 1218 solve the security problems of record and source route. 1220 Compared to MIPv6, the main security problem seems to be the fact 1221 that the RRH can be modified in transit by an attacker on the path. 1222 It has to be noted that such an attacker (for example any MR in the 1223 Mobile Network) can perform more effective attacks than modifying the 1224 RRH. 1226 12.1. IPsec Processing 1228 The IPsec [17] AH [18] and ESP [19] can be used in tunnel mode to 1229 provide different security services to the tunnel between a MR and 1230 its HA. ESP tunnel mode SHOULD be used to provide confidentiality 1231 and authentication to the inner packet. AH tunnel mode MUST be used 1232 to provide authentication of the outer IP header fields, especially 1233 the Routing Headers. 1235 12.1.1. Routing Header type 2 1237 Due to the possible usage of Doors [4] to enable IPv4 traversal, the 1238 Routing Header type 2 cannot be treated as type 0 for the purpose of 1239 IPsec processing (i.e. it cannot be included in its intirety in the 1240 Integrity Check Value (ICV) computation, because NAT/PAT may mangle 1241 one of the MR care-of-addresses along the HA-MR path. 1243 The sender (the HA) will put the slot 0 entry (the MR Home Address) 1244 of the RH as destination of the outer packet, will zero out 1245 completely the Routing Header and will perform the ICV computation. 1247 The receiver (the MR) will put the slot 0 entry as destination of the 1248 outer packet, will zero out the Routing Header and will perform the 1249 ICV validation. 1251 12.1.2. Routing Header type 4 1253 The Routing Header type 4 is "partially mutable", and as such can be 1254 included in the Authentication Data calculation. Given the way type 1255 4 is processed, the sender cannot order the field so that it appears 1256 as it will at the receiver; this means the receiver will have to 1257 shuffle the fields. 1259 The sender (the MR) will zero out all the slots and the Segment Used 1260 field of the RRH, and will put as source address of the outer packet 1261 its Home Address, and then will perform the ICV computation. 1263 The receiver (the HA) will put the entry in slot 0 (the MR Home 1264 Address) in the source address and will zero out all the slots and 1265 the Segment Used field of the RRH, and then will perform the ICV 1266 verification. 1268 12.2. New Threats 1270 The RH type 4 is used to construct a MIPv6 RH type 2 with additional 1271 semantics, as described in Section 4.1. Since RH type 2 becomes a 1272 multi hop option like RH type 0, care must be applied to avoid the 1273 spoofing attack that can be performed with the IPv4 source route 1274 option. This is why IPv6 [13] takes special care in responding to 1275 packets carrying Routing Headers. 1277 AH authenticates the MR Home Address identity and the RRH sequence 1278 number. The RRH sequence number is to be used to check the freshness 1279 of the RRH; anti-replay protection can be obtained if the receiver 1280 enables the anti-replay service of AH [18]. 1282 In particular, if IPSec is being used, the content is protected and 1283 can not be read or modified, so there is no point in redirecting the 1284 traffic just to screen it. 1286 Say a MR in a nested structure modifies the RRH in order to bomb a 1287 target outside of the tree. If that MR forwards the packet with 1288 itself as source address, the MR above it will make sure that the 1289 response packets come back to the attacker first, since that source 1290 is prepended to the RRH. If it forges the source address, then the 1291 ingress filtering at the MR above it should detect the irregularity 1292 and drop the packet. Same if the attacker is actually TLMR. The 1293 conclusion is that ingress filtering is recommended at MR and AR. 1295 Say that an attacker in the infrastructure and on the path of the 1296 MRHA tunnel modifies the RRH in order to redirect the response 1297 packets and bomb a target. Considering the position of the attacker 1298 - a compromised access or core router - there's a lot more it could 1299 do to send perturbations to the traffic, like changing source and 1300 destinations of packets on the fly or eventually pollute the routing 1301 protocols. 1303 Say a MR in a nested structure modifies the RH 2 in order to attack a 1304 target outside of the tree. The RH type 2 forwarding rules make sure 1305 that the packet can only go down a tree. So unless the attacker is 1306 TLMR, the packet will not be forwarded. In any case, the attacker 1307 will be bombed first. 1309 Say that an attacker on the path of the MRHA tunnel modifies the RRH 1310 in order to black out the MR. The result could actually be 1311 accomplished by changing any bit in the packet since the IPSec 1312 signature would fail, or scrambling the radio waves in the case of 1313 wireless. 1315 Selecting the tree to attach to is a security critical operation 1316 outside of the scope of this draft. Note that the MR should not 1317 select a path based on trust but rather on measured service. If a 1318 better bandwidth is obtained via an untrusted access using IPSec, 1319 isn't it better than a good willing low bandwidth trusted access? 1321 Yet, the CoA and the RRH are not protected on the way and might be 1322 modified by a rogue router in the middle. Also, if proper SeND [20] 1323 is not in place in the visited network, the MR might be fooled into 1324 autoconfiguring a CoA from a prefix that does not exist or is not 1325 actually there. This draft proposes in Section 6 an optional Reverse 1326 Routability test to confirm that the MR is reachable at the CoA via 1327 the RRH. 1329 13. IANA considerations 1331 This document requires IANA to define 2 new IPv6 Routing Header 1332 types. 1334 14. Protocol Constants 1336 DEF_RRH_SLOTS: 7 1338 MAX_RRH_SLOTS: 10 1340 15. Acknowledgements 1342 The authors wish to thank David Auerbach, Fred Baker, Dana Blair, 1343 Steve Deering, Dave Forster, Thomas Fossati, Francois Le Faucheur, 1344 Kent Leung, Massimo Lucchina, Vincent Ribiere, Dan Shell and Patrick 1345 Wetterwald -last but not least :)-. 1347 16. References 1349 16.1. informative reference 1351 [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1352 draft-ietf-nemo-terminology-06 (work in progress), 1353 November 2006. 1355 [2] Thubert, P., "Nested Nemo Tree Discovery", 1356 draft-thubert-tree-discovery-04 (work in progress), 1357 November 2006. 1359 [3] Thubert, P., "NEMO Home Network models", 1360 draft-ietf-nemo-home-network-models-06 (work in progress), 1361 February 2006. 1363 [4] Thubert, P., Molteni, M., and P. Wetterwald, "IPv4 traversal 1364 for MIPv6 based Mobile Routers", 1365 draft-thubert-nemo-ipv4-traversal-01 (work in progress), 1366 May 2003. 1368 [5] Devarapalli, V., "Local HA to HA protocol", 1369 draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), 1370 March 2006. 1372 [6] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 1373 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 1374 progress), May 2006. 1376 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 1377 draft-ietf-nemo-requirements-06 (work in progress), 1378 November 2006. 1380 [8] Ng, C., "Analysis of Multihoming in Network Mobility Support", 1381 draft-ietf-nemo-multihoming-issues-06 (work in progress), 1382 June 2006. 1384 16.2. normative reference 1386 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", 1387 RFC 3753, June 2004. 1389 [10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1390 IPv6", RFC 3775, June 2004. 1392 [11] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1393 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1394 January 2005. 1396 [12] Postel, J., "Internet Protocol", STD 5, RFC 791, 1397 September 1981. 1399 [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1400 Specification", RFC 2460, December 1998. 1402 [14] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 1403 line Database", RFC 3232, January 2002. 1405 [15] Conta, A. and S. Deering, "Internet Control Message Protocol 1406 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1407 Specification", RFC 2463, December 1998. 1409 [16] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1410 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1412 [17] Kent, S. and R. Atkinson, "Security Architecture for the 1413 Internet Protocol", RFC 2401, November 1998. 1415 [18] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1416 November 1998. 1418 [19] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1419 (ESP)", RFC 2406, November 1998. 1421 [20] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1422 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1424 Appendix A. Optimizations 1426 A.1. Path Optimization with RRH 1428 The body of the draft presents RRH as a header that circulates in the 1429 reverse tunnel exclusively. The RRH format by itself has no such 1430 limitation. This section illustrates a potential optimization for 1431 end-to-end traffic between a Mobile Network Node and its 1432 Correspondent Node. 1434 The MNN determines that it is part of a Mobile Network by screening 1435 the Tree Information option in the RA messages from its Attachment 1436 Router. In particular, the MNN knows the TreeDepth as advertised by 1437 the AR. An initial test phase could be derived from MIPv6 to decide 1438 whether optimization with a given CN is possible. 1440 When an MNN performs end-to-end optimization with a CN, the MNN 1441 inserts an empty RRH inside its packets, as opposed to tunneling them 1442 home, which is the default behavior of a Mobile Host as described in 1443 Section 11. 1445 The number of slots in the RRH is initially the AR treeDepth plus 1, 1446 but all slots are clear as opposed to the MR process as described in 1447 Section 10. The source address in the header is the MNN address, and 1448 the destination is the CN. 1450 The AR of the MNN is by definition an MR. Since an RRH is already 1451 present in the packet, the MR does not put the packets from the MNN 1452 on its reverse tunnel, but acts as an intermediate MR; it adds the 1453 source address of the packet (the MNN's address) in the RRH (in slot 1454 0) and stamps its careOf instead in the IP header source address 1455 field. Recursively, all the MRs on a nested network trace in path in 1456 the RRH and take over the source IP. 1458 The support required on the CN side extends MIPv6 in a way similar to 1459 the extension that this draft proposes for the HA side. The CN is 1460 required to parse the RRH when it is valid, refresh its BCE 1461 accordingly, and include an RH type 2 with the full path to its 1462 packets to the MNN. 1464 Note that there is no Bind Update between the MNN and the CN. The 1465 RRH must be secured based on tokens exchanged in the test phase. For 1466 the sake of security, it may be necessary to add fields to the RRH or 1467 to add a separate option in the Mobility Header. 1469 A.2. Packet Size Optimization 1471 RRH allows to update the Correspondent BCE on a per packet basis, 1472 which is the highest resolution that we can achieve. While this may 1473 cope with highly mobile and nested configurations, it can also be an 1474 overkill in some situations. 1476 The RRH comes at a cost: it requires processing in all intermediate 1477 Mobile Routers and in the Correspondent Node. Also, a RRH increases 1478 the packet size by more than the size of an IP address per hop in the 1479 Mobile Network. 1481 This is why an additional Routing Header is proposed (type 3). The 1482 semantics of type 3 are very close to type 4 but: 1484 o Type 3 has only one slot, for the Home Address of the source. 1486 o When it can not add the source to the RH type 3 of an outbound 1487 packet, an intermediate MR: 1489 * MR MUST NOT send ICMP (RRH too small) 1491 * MUST NOT put the packet in a reverse tunnel 1493 Rather, it simply overwrites the source and forwards the packet up 1494 the tree as if the RRH had been properly updated. 1496 o Since the path information is not available, the correspondent 1497 MUST NOT update its BCE based on the RH type 3. The CN (or HA) 1498 identifies the source from the entry in slot 0 and may reconstruct 1499 the initial packet using the CareOf in slot 1 as source for AH 1500 purposes. 1502 /* MR processing on outbound packet with RH type 3 support */ 1503 { 1505 if no RH type 3 or 4 in outer header /* Case of first MR */ 1506 or RH type 4 present but saturated { /* Causing nested encap */ 1508 if RRH is saturated { 1509 do ICMP back (RRH too small) 1510 } 1512 /* put packet in sliding reverse tunnel */ 1513 insert new IP header plus RRH 1514 set source address to the MR Home Address 1515 set destination address to the MR Home Agent Address 1516 add an RRH with all slots zeroed out 1517 compute IPsec AH on the resulting packet 1518 } 1520 /* All MRs including first */ 1521 if packet size > MTU { 1522 do ICMP back (Packet too Big) 1523 } else if RRH { 1524 select first free slot in RRH bottom up 1525 set it to source address from IP header 1526 overwrite source address in IP header with MR CareOf 1527 transmit packet 1528 } else if RH type 3 { 1529 if slot 0 is still free { 1530 /* this is end-to-end optimization */ 1531 set it to source address from IP header 1532 } 1533 overwrite source address in IP header with MR CareOf 1534 transmit packet 1535 } 1536 } 1538 A.2.1. Routing Header Type 3 (Home Address option replacement) 1540 This is an RH-based alternative to the Home Address destination 1541 option. Its usage is described in Appendix A.2. 1543 The decision to send RH type 3 or type 4 is up to the source of the 1544 RRH. Several algorithms may apply, one out of N being the simplest. 1546 IPsec HA processing is done as described in Section 12.1 for Type 4. 1548 The Type 3 Routing Header has the following format: 1550 0 1 2 3 1551 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 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Next Header | Hdr Ext Len | Routing Type=3| Segments Used | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Reserved | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | | 1558 + + 1559 | | 1560 + Home Address + 1561 | | 1562 + + 1563 | | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Next Header 1568 8-bit selector. Identifies the type of header immediately 1569 following the Routing header. Uses the same values as the IPv4 1570 Protocol field [14]. 1572 Hdr Ext Len 1574 8-bit unsigned integer. Length of the Routing header in 8-octet 1575 units, not including the first 8 octets. For the Type 3 Routing 1576 header, Hdr Ext Len is always 2. 1578 Routing Type 1580 8-bit unsigned integer. Set to 3. 1582 Segment Used 1584 8-bit unsigned integer. Number of slots used. Either 0 or 1. 1585 When the field is zero, then there is no MR on the path and it is 1586 valid for a CN that does not support RRH to ignore this header. 1588 Reserved 1590 32-bit reserved field. Initialized to zero for transmission; 1591 ignored on reception. 1593 Home Address 1595 128-bit home address of the source of the packet. 1597 Appendix B. Multi Homing 1599 B.1. Multi-Homed Mobile Network 1601 Consider difference between situation A and B in this diagram: 1603 ===?== ==?=== 1604 MR1 MR2 1605 | | 1606 ==?=====?== ==?====== situation A 1607 MR3 MR4 MR5 1608 | | | 1609 === === === 1611 ===?== ==?=== 1612 MR1 MR2 1613 | | 1614 ==?=====?=======?====== situation B 1615 MR3 MR4 MR5 1616 | | | 1617 === === === 1619 Going from A to B, MR5 may now choose between MR1 and MR2 for its 1620 Attachment (default) Router. In terms of Tree Information, MR5, as 1621 well as MR3 and MR4, now sees the MR1's tree and MR2's tree. Once 1622 MR5 selects its AR, MR2, say, MR5 belongs to the associated tree and 1623 whether MR1 can be reached or not makes no difference. 1625 As long as each MR has a single default router for all its outbound 1626 traffic, 2 different logical trees can be mapped over the physical 1627 configurations in both situations, and once the trees are 1628 established, both cases are equivalent for the processing of RRH. 1630 Note that MR5 MUST use a CareOf based on a prefix owned by its AR as 1631 source of the reverse tunnel, even if other prefixes are present on 1632 the Mobile Network, to ensure that a RH type 2 can be securely routed 1633 back. 1635 B.2. Multihomed Mobile Router 1637 Consider the difference between situation B and C in this diagram: 1639 ===?== ==?=== 1640 MR1 MR2 1641 | | 1642 ==?=====?=======?====== situation B 1643 MR3 MR4 MR5 1644 | | | 1645 === === === 1647 ==? ?== 1648 MR1 1649 | 1650 ==?=====?=======?====== situation C 1651 MR3 MR4 MR5 1652 | | | 1653 === === === 1655 In situation C, MR2's egress interface and its properties are 1656 migrated to MR1. MR1 has now 2 different Home Addresses, 2 Home 1657 Agents, and 2 active interfaces. 1659 If MR1 uses both CareOf addresses at a given point of time, and if 1660 they belong to different prefixes to be used via different attachment 1661 routers, then MR1 actually belongs to 2 trees. It must perform some 1662 routing logic to decide whether to forward packets on either egress 1663 interface. Also, it MUST advertise both tree information sets in its 1664 RA messages. 1666 The difference between situations C and B is that when an attached 1667 router (MR5, say) selects a tree and forwards egress packets via MR1, 1668 it can not be sure that MR1 will actually forward the packets over 1669 that tree. If MR5 has selected a given tree for a specific reason, 1670 then a new source route header is needed to enforce that path on MR1. 1672 The other way around, MR5 may leave the decision up to MR1. If MR1 1673 uses the same attachment router for a given flow or at least a given 1674 destination, then the destination receives consistent RRHs. 1675 Otherwise, the BCE cache will flap, but as both paths are valid, the 1676 traffic still makes it through. 1678 Appendix C. Changes from Previous Version of the Draft 1680 From -06 to -07 1682 Added a reverse Routability test. 1684 From -04 to -05 1686 Tree Information option: now a reference to a separate draft. 1688 Removed RRH heartbeat. 1690 Added a DHAAD section 1692 Clarified how RRH solves the mobile home deadlock. 1694 new section "Optimum number of slots in RRH" from ICMP section 1696 From -03 to -04 1698 TI option: renamed the F (fixed) flag bit to G (grounded). 1700 Binding Update: Made clear that the BU flow conforms MIPv6 and 1701 NEMO but that RRH replaces both Home address Option and Alternate 1702 CareOf option. 1704 From -02 to -03 1706 Reworded the security part to remove an ambiguity that let the 1707 reader think that RRH is unsafe. 1709 From -01 to -02 1711 Made optional the usage of ICMP warning "RRH too small" 1712 (Section 5). 1714 Changed the IPsec processing for Routing Header type 2 1715 (Section 12.1). 1717 From -00 to -01 1719 Added new Tree Information Option fields: 1721 A 8 bits Bandwidth indication that provides an idea of the 1722 egress bandwidth. 1724 A CRC-32 that changes with the egress path out of the tree. 1726 a 32 bits unsigned integer, built by each MR out of a high 1727 order configured preference and 24 bits random constant. This 1728 can help as a tie break in Attachment Router selection. 1730 Reduced the 'negative' part of the lollipop space to 0..255 1732 Fixed acknowledgements (sorry Patrick :) 1734 Changed the type of Tree Information Option from 7 to 10. 1736 Authors' Addresses 1738 Pascal Thubert 1739 Cisco Systems Technology Center 1740 Village d'Entreprises Green Side 1741 400, Avenue Roumanille 1742 Biot - Sophia Antipolis 06410 1743 FRANCE 1745 Email: pthubert@cisco.com 1747 Marco Molteni 1748 Cisco Systems Technology Center 1749 Village d'Entreprises Green Side 1750 400, Avenue Roumanille 1751 Biot - Sophia Antipolis 06410 1752 FRANCE 1754 Email: mmolteni@cisco.com 1756 Full Copyright Statement 1758 Copyright (C) The IETF Trust (2007). 1760 This document is subject to the rights, licenses and restrictions 1761 contained in BCP 78, and except as set forth therein, the authors 1762 retain all their rights. 1764 This document and the information contained herein are provided on an 1765 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1766 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1767 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1768 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1769 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1770 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1772 Intellectual Property 1774 The IETF takes no position regarding the validity or scope of any 1775 Intellectual Property Rights or other rights that might be claimed to 1776 pertain to the implementation or use of the technology described in 1777 this document or the extent to which any license under such rights 1778 might or might not be available; nor does it represent that it has 1779 made any independent effort to identify any such rights. Information 1780 on the procedures with respect to rights in RFC documents can be 1781 found in BCP 78 and BCP 79. 1783 Copies of IPR disclosures made to the IETF Secretariat and any 1784 assurances of licenses to be made available, or the result of an 1785 attempt made to obtain a general license or permission for the use of 1786 such proprietary rights by implementers or users of this 1787 specification can be obtained from the IETF on-line IPR repository at 1788 http://www.ietf.org/ipr. 1790 The IETF invites any interested party to bring to its attention any 1791 copyrights, patents or patent applications, or other proprietary 1792 rights that may cover technology that may be required to implement 1793 this standard. Please address the information to the IETF at 1794 ietf-ipr@ietf.org. 1796 Acknowledgment 1798 Funding for the RFC Editor function is provided by the IETF 1799 Administrative Support Activity (IASA).