idnits 2.17.1 draft-bernardos-mext-nemo-ro-cr-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1011. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1035. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (July 7, 2008) is 5772 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-08 == Outdated reference: A later version (-04) exists of draft-ietf-mext-aero-reqs-02 == Outdated reference: A later version (-02) exists of draft-ietf-mext-nemo-ro-automotive-req-00 == Outdated reference: A later version (-01) exists of draft-bauer-mext-aero-topology-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group C. Bernardos 3 Internet-Draft M. Calderon 4 Intended status: Experimental I. Soto 5 Expires: January 8, 2009 UC3M 6 July 7, 2008 8 Correspondent Router based Route Optimisation for NEMO (CRON) 9 draft-bernardos-mext-nemo-ro-cr-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 The Network Mobility Basic Support protocol enables networks to roam 39 and attach to different access networks without disrupting the 40 ongoing sessions that nodes of the network may have. By extending 41 the Mobile IPv6 support to Mobile Routers, nodes of the network are 42 not required to support any kind of mobility, since packets must go 43 through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. 44 Communications from/to a mobile network have to traverse the Home 45 Agent, and therefore better paths may be available. Additionally, 46 this solution adds packet overhead, due to the encapsulation. 48 This document describes an approach to the Route Optimisation for 49 NEMO, based on the well-known concept of Correspondent Router. The 50 solution aims at meeting the currently identified NEMO Route 51 Optimisation requirements for Operational Use in Aeronautics and 52 Space Exploration. Based on the ideas that have been proposed in the 53 past, as well as some other extensions, this document describes a 54 Correspondent Router based solution, trying to identify the most 55 important open issues. 57 The main goal of this first version of the document is to describe an 58 initial NEMO RO solution based on the deployment of Correspondent 59 Routers and trigger the discussion within the MEXT WG about this kind 60 of solution. 62 This document (in an appendix) also analyses how a Correspondent 63 Router based solution fits each of the currently identified NEMO 64 Route Optimisation requirements for Operational Use in Aeronautics 65 and Space Exploration. 67 Requirements Language 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [1]. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.1. Correspondent Router Prefix Option . . . . . . . . . . . . 7 79 4. Mobile Router operation . . . . . . . . . . . . . . . . . . . 8 80 4.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 8 81 4.2. Correspondent Router Discovery . . . . . . . . . . . . . . 9 82 4.3. Correspondent Router Binding . . . . . . . . . . . . . . . 10 83 5. Correspondent Router operation . . . . . . . . . . . . . . . . 12 84 5.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 12 85 5.2. Correspondent Router Binding . . . . . . . . . . . . . . . 13 86 5.3. Intercepting Packets from a Correspondent Node . . . . . . 13 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 93 Appendix A. Analysis of CRON and the Aeronautics requirements . . 16 94 A.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 16 95 A.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 17 96 A.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 17 97 A.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 18 98 A.5. Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 18 99 A.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 19 100 A.7. Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 19 101 A.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 20 102 A.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 20 103 A.10. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 20 104 A.11. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 21 105 A.12. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 21 106 A.13. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 21 107 A.14. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 21 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 109 Intellectual Property and Copyright Statements . . . . . . . . . . 23 111 1. Introduction 113 This document assumes that the reader is familiar with the 114 terminology related to Network Mobility [5] and [6] (Figure 1), and 115 with the Mobile IPv6 [2] and NEMO Basic Support [3] protocols. 117 The goals of the Network Mobility (NEMO) Support are described in 118 [7]. Basically, the main goal is to enable networks to move while 119 preserving the communications of their nodes (Mobile Network Nodes, 120 or MNNs), without requiring any mobility support on them. The NEMO 121 Basic Support protocol [3] consists on setting a bi-directional 122 tunnel (Figure 2) between the Mobile Router (MR) of the network (that 123 connects the mobile network to the Internet) and its Home Agent 124 (located at the Home Network of the mobile network). This is 125 basically the Bi-directional Tunnel (BT) operation of Mobile IPv6 126 (MIPv6) [2], but without supporting Route Optimisation. Actually, 127 the protocol extends the existing MIPv6 Binding Update (BU) message 128 to inform the Home Agent (HA) of the current location of the mobile 129 network (i.e. the MR's Care-of Address, CoA), through which the HA 130 has to forward the packets addressed to the network prefix managed by 131 the MR (Mobile Network Prefix, or MNP). 133 --------- 134 | HA_MR | 135 --------- 136 | 137 ------ +-----------+---------+ 138 | CN |----| Internet | 139 ------ +---+-----------------+ 140 | 141 ------ ------------------------------ 142 | AR | | AR: Access Router | 143 ------ | CN: Correspondent Node | 144 | | MR: Mobile Router | 145 ===?========== | HA_MR: MR's Home Agent | 146 MR | MNP: Mobile Network Prefix | 147 | | MNN: Mobile Network Node | 148 ===|========|====(MNP) ------------------------------ 149 MNN MNN 151 Figure 1: Basic scenario of Network Mobility 153 Because of the bi-directional tunnel that is established between HA 154 and MR to transparently enable the movement of networks, the NEMO 155 Basic Support protocol introduces the following limitations: 156 o It forces suboptimal routing (known as angular or triangular 157 routing), since packets are always forwarded through the HA 158 following a suboptimal path and therefore adding a delay in the 159 packet delivery. 160 o It introduces non-negligible packet overhead, reducing the Path 161 MTU (PMTU). An additional IPv6 header (40 bytes) is added to 162 every packet because of the MRHA bi-directional tunnel. 163 o The HA becomes a bottleneck of the communication. This is 164 because, even if a direct path is available between a MNN and a 165 CN, the NEMO Basic Support protocol forces traffic to follow the 166 CN-HA=MR-MNN path. This may cause the Home Link to be congested, 167 resulting in some packets discarded. 169 In order to overcome such limitations, it is necessary to provide 170 what have been called Route Optimisation for NEMO [8], [9], [10], 171 [11]. 173 __ _____ __ ___ 174 | | | | | | | | 175 |CN| |HA_MR| |MR| |MNN| 176 |__| |_____| |__| |___| 177 | | | | 178 | ------------ | ------------------------------ | ------------ | 179 | |S:CN,D:MNN| | |S:HA_MR,D:MR_CoA[S:CN,D:MNN]| | |S:CN,D:MNN| | 180 | | DATA | | | DATA | | | DATA | | 181 | ------------ | ------------------------------ | ------------ | 182 |-------------->|-------------------------------->|-------------->| 183 | | | | 184 | ------------ | ------------------------------ | ------------ | 185 | |S:MNN,D:CN| | |S:MR_CoA,D:HA_MR[S:MNN,D:CN]| | |S:MNN,D:CN| | 186 | | DATA | | | DATA | | | DATA | | 187 | ------------ | ------------------------------ | ------------ | 188 |<--------------|<--------------------------------|<--------------| 189 | | | | 191 Figure 2: NEMO Basic Support protocol 193 This document collects some ideas about a Route Optimisation scheme 194 based on optimising the routing path between an MNN and a CN by 195 setting up a bi-directional tunnel between the MR of the NEMO and a 196 router topologically close to the CN, called Correspondent Router 197 (CR). Packets of the communication between the MNN and the CN could 198 then use this bi-directional tunnel instead of the default MRHA one, 199 in this way optimising the resulting routing path. 201 While this idea is far from being new ([12], [9]), the re-chartering 202 of the MEXT WG (formerly NEMO WG) to specifically address and work on 203 the design of a solution targeting a set of particular use case 204 scenarios (namely aeronautics [13], vehicular [14] and consumer 205 electronics [15]) makes worthwhile revisiting the idea of a CR-based 206 NEMO RO solution and analyse whether this kind of approach would fit 207 the requirements of those scenarios. This document is a first 208 attempt of doing so, focused on the requirements for Operational Use 209 in Aeronautics and Space Exploration. 211 2. Protocol Overview 213 The approach described in this document, called Correspondent Router 214 based Route Optimisation for NEMO (CRON), is based on the idea of 215 extending the NEMO Basic Support protocol [3] to enable the MR 216 managing bindings not only with the HA, but also with special 217 routers, called Correspondent Routers (CRs), so the MRHA tunnel can 218 be bypassed for traffic addressed to CNs that are topologically close 219 to a CR. 221 CRON basically works as follows: an MR is forwarding packets to 222 several communications between MNNs of the NEMO and CNs located in 223 the Internet. For some of these communications, the MR may decide 224 that it is better to try to avoid the use of the MRHA tunnel and try 225 to set up a binding with a CR close to the other end-point of the 226 communication (i.e. the CN). In order to do so, the MR needs to know 227 whether there are any potential CRs that can be used and their IPv6 228 addresses. Once the MR knows that, it can select a CR among the 229 potential ones (if any) and decide to establish a binding with it. 230 To do so, a Binding Update/Binding Acknowledgement message exchange 231 takes place. Once the signalling has occurred, the MR sets up a bi- 232 directional tunnel with the CR and adds a routing entry towards the 233 IPv6 prefix/address managed by the CR (the CN prefix), using the CR 234 as next hop (through the established tunnel). Analogously, the CR 235 sets up a routing entry towards the MNP/MNN IPv6 address, using the 236 MR's CoA as next hop through the established tunnel. At this point, 237 the traffic between the MNN (or set of MNNs with IPv6 addresses from 238 a particular MNP) and the CN (or set of CNs with IPv6 addresses from 239 a particular CN prefix) no longer traverses the HA, since the bi- 240 directional tunnel established between the MR and the CR is used 241 instead. 243 Next sections of this document describe in more detail the operation 244 of CRON. It is not the goal of this first version to provide a 245 complete and exhaustive specification (many details are not 246 included), but rather to list the key operations that would be 247 required for such a CR-based solution work, and, more importantly, 248 identify the key requirements/assumptions/open issues that remain to 249 be solved. This last point would be potentially very dependant on 250 the considered NEMO RO use case. 252 3. Message Formats 254 3.1. Correspondent Router Prefix Option 256 The Correspondent Router Prefix Option is included in the Binding 257 Updates to indicate to the Correspondent Router the CN prefix (could 258 also be a host address) that is requested to be route optimised. 259 This information and the prefix included in the Mobile Network Prefix 260 Option ([3]) is used by the CR to know which packets have to be sent 261 through the MR-CR bi-directional tunnel. There could be multiple 262 Correspondent Router Prefix Options if the CR is able to route 263 optimise traffic from different CN prefixes and the MR wants traffic 264 from more than one of these prefixes to be optimised. This option is 265 also included by the CR in the BA messages. 267 The Correspondent Router Prefix Option has an alignment requirement 268 of 8n+4. Its format is as follows. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type | Length | Reserved | Prefix Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 + + 277 | | 278 + Correspondent Router Prefix + 279 | | 280 + + 281 | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Type: 285 Number to be assigned by IANA. 287 Length: 288 Eight-bit unsigned integer indicating the length in octets of the 289 option, excluding the type and length fields. Set to 18. 291 Reserved: 292 This field is unused for now. The value MUST be initialized to 0 293 by the sender and MUST be ignored by the receiver. 295 Prefix Length: 296 Eight-bit unsigned integer indicating the prefix length of the 297 IPv6 prefix contained in the option. 299 Correspondent Router Prefix: 301 A sixteen-byte field containing the Correspondent Router Prefix. 303 4. Mobile Router operation 305 The Mobile Router operation defined by the NEMO Basic Support 306 protocol [3] is extended in order to be able to set up bindings with 307 different CRs and establish bi-directional tunnels with them, used to 308 route part of the traffic as indicated by the MR's policies. 310 The process of NEMO RO set-up MUST be initiated by the MR, and cannot 311 be initiated by the CR. Next sections elaborate more on the 312 different operations and mechanisms required to complete the whole 313 NEMO RO. 315 4.1. Conceptual Data Structures 317 In addition to the data structures defined in [3], the MR needs also 318 to maintain the following information: 320 o The MR extends the Binding Update List (BUL) to contain also some 321 information per each communication that is being route optimised. 322 Basically the added fields are the following: 323 * A flag specifying whether the entry is a Correspondent Router 324 entry or not. 325 * Source IPv6 optimised prefix: this field contains the IPv6 326 address/prefix of those MNNs whose traffic is being optimised 327 by using an MR-CR bi-directional tunnel with the CR. There 328 could be multiple instances of this field in the BUL of the MR. 329 These are basically the IPv6 addresses/prefixes included in the 330 Mobile Network Prefix options carried in the BU/BA signalling 331 exchanged by the MR and the CR. 332 * Destination IPv6 optimised prefix: this field contains the IPv6 333 address/prefix of those CNs whose traffic is being optimised by 334 using an MR-CR bi-directional tunnel with the CR. There could 335 be multiple instances of this field in the BUL of the MR. 336 These are basically the IPv6 addresses/prefixes included in the 337 Correspondent Router Prefix options carried in the BU/BA 338 signalling exchanged by the MR and the CR. 339 o The MR SHOULD have a policy database that contains information 340 regarding which communications should be route optimised and which 341 not. It is up to the implementation the decision about the exact 342 content of this database, as well as if it can be dynamically 343 updated or it is pre-configured statically. 345 4.2. Correspondent Router Discovery 347 Prior to the binding establishment and tunnel set-up between an MR 348 and a CR, the MR MUST find out whether there exist a CR that can be 349 used to optimise the route between an attached MNN (or set of MNNs, 350 having IPv6 addresses from the same MNP) and a CN (or set of CNs, 351 having IPv6 addresses from the same IPv6 prefix). Besides, if there 352 exist such a CR, the MR needs to know some information about it, such 353 CR's IPv6 address. 355 This information may be known beforehand by the MR, by means of a 356 static pre-configuration of the list of usable CRs and some 357 additionally required information. Although it is up to the 358 implementers to decide how this static information has to be 359 processed and handled, the CR information MAY be indexed in a manner 360 similar to a routing table, so when an MR has a target IPv6 address/ 361 prefix to which it wants to search for a candidate CR, it can perform 362 a look-up in the CR database and get the most suitable CR (that is, 363 the CR that is topologically closest to the target, using the 364 longest-match prefix rule). 366 Although a static configuration might be enough for several 367 scenarios, it seems desirable to support dynamic CR discovery. This 368 is one of the hardest problems that a CR-based solution poses. There 369 have been different proposals to tackle this problem. We next 370 present the fundamentals of some of those, as well as some new ones: 372 o If the CR is assumed to be always on the path between the MR to 373 the CN (e.g., the CR is the gateway of the CN), the CR could 374 inspect all received packets looking for a particular message. In 375 this way, when there is a communication that is a candidate for 376 being route optimised, the MR can send a BU message to the CN. If 377 there is a CR available, the first CR on the path towards the CN 378 would capture that packet (not forwarding it to the next hop) and 379 process it accordingly. This approach seems to have severe 380 limitations, since it assumes that available CRs will always be on 381 the MR-CN path, but it deserves to be listed as it might be the 382 case that this assumption is reasonable for some of the use cases 383 currently considered by the MEXT WG. 384 o Discovery based on/assisted by the DNS. The DNS service might be 385 used in different ways, such as adding new type of registers, or 386 including an 'A' register for the CR of each particular domain. 387 In the latter case, the solution would work as follows: an MR 388 attempting to optimise a certain MNN-CN communication would 389 perform a reverse DNS query -- using the IPv6 address of the CN -- 390 to obtain the qualified DNS name of the CN. Using the obtained 391 name, the MR would perform a query of the name 'CR.domainname', 392 where 'domainname' is the domain part of the previously obtained 393 name. The 'A' register of 'CR.domainname' would contain (if that 394 CR exists) the IPv6 address(es) of the CR(s) of that domain. This 395 solution has also some drawbacks, since it assumes that each 396 potential CN has a domain name published in the DNS, and assumes 397 that all nodes belonging to a topological domain share the same 398 domain names. 399 o Use of a CR anycast address. The ORC draft [12] proposes the 400 definition of anycast addresses for the CRs. In this way, the MR 401 learns the CR anycast address from the CN's prefix and the defined 402 anycast suffix. Using this anycast address, the MR sends CR 403 discovery requests, waiting for CR discovery replies, in a way 404 similar to the DHAAD mechanism of Mobile IPv6 [2]. This mechanism 405 shares the limitations of DHAAD. 406 o Deployment of CR-resolver servers. Given that some of the 407 currently addressed use cases involve kind-of controlled 408 environments, where certain trust relationships might be safely 409 assumed, the deployment of a (potentially distributed, even in a 410 hierarchical way) CR-resolver service may be considered. These 411 CR-resolver servers would keep the a repository of CR-related 412 information, including the IPv6 address of the CRs managing a 413 particular IPv6 prefix/address. Every CR should keep that 414 repository updated, so MRs can send queries to look for candidate 415 CRs (the CR-resolver service would return the best CR, that is the 416 one serving the longest-match prefix). In order to ensure the 417 integrity of the stored information, CRs MUST have some type of 418 security relationship with the CR-resolver service, so only 419 authorised CRs can modify the stored information. Analogously, 420 MRs SHOULD also have some trust relationship, so the MR is 421 provided with some security guarantees regarding the authenticity 422 of the information retrieved from CR-resolvers. It is also worth 423 evaluating if it would be better that the HA is the one querying 424 the CR-resolvers, and that the obtained information is provided to 425 the MR through the HA (it might reduce the bandwidth consumption 426 on the MR wireless access links and also reduce the number of 427 required trust relationships). Both the requirement of deploying 428 this CR-resolver service and the assumption of the existence of 429 trust relationships should be carefully analysed for each of the 430 currently addressed NEMO RO scenarios, in order to evaluate 431 whether they are reasonable or not. This CR discovery approach 432 needs further work, TBD after gathering WG feedback about it. 434 4.3. Correspondent Router Binding 436 Once the MR has learnt the IPv6 address of a CR that can be used to 437 route optimise some traffic, it needs to perform the Binding 438 Registration to this CR. The MR sends a Binding Update message 439 protected with IPsec/IKE. It is assumed that MRs would have 440 certificates that contain information regarding the Mobile Network 441 Prefixes they are authorised to manage and their Home Address. It is 442 also assumed that CRs would trust on those certificates, for example 443 by means of a shared PKI infrastructure. Again, it needs to be 444 discussed whether this assumption is too strong or it is reasonable 445 for a given NEMO RO scenario (it seems that for AOS domain this 446 requirement is less strong than for ATS domains [16]). 448 The Binding Update sent by the MR to the CR MUST have the Mobile 449 Router (R) Flag set to 1, indicating to the CR that the BU is from an 450 MR. The Home Registration (H) Flag MUST be set to 0. In this way, a 451 CR that also implements the Home Agent functionality can 452 differentiate Home Registration Binding requests from Correspondent 453 Router Binding requests. 455 All BUs sent by MRs to CRs requesting a Correspondent Router Binding 456 MUST carry at least a Mobile Network Prefix Option, containing the 457 IPv6 prefix/address of the MNN(s) whose traffic is requested to be 458 optimised. Therefore, only explicit binding mode is supported. 460 All BUs sent by MRs to CRs requesting a Correspondent Router Binding 461 MUST carry at least a Correspondent Router Prefix Option, containing 462 the IPv6 prefix/address of the CN(s) whose traffic is requested to be 463 optimised. Traffic generated by nodes whose IPv6 addresses are not 464 from the prefixes contained in these option, with destination the 465 MNPs contained in the Mobile Network Prefix Option, MUST NOT be route 466 optimised (the normal route MUST be used instead). 468 An MR MUST generate a different BU message per each MNN-CN (or MNP-CN 469 Prefix) pair that wants to be optimised. Note that a binding is not 470 restricted to the optimisation of traffic between an individual MNN 471 and an individual CN, and can be established on an MNP-CN prefix 472 basis. The CRON mechanism aims at providing the flexibility required 473 to support this granularity. Each BU contains the MNP prefix/MNN 474 address information in the Mobile Network Prefix Options and the CN 475 address/prefix information in the Correspondent Router Prefix Option. 477 The CR should be able to validate the CoA ownership claimed by the MR 478 (that is, that the MR is actually reachable at its CoA). Depending 479 on the considered use case, it might not be enough to rely on ingress 480 filtering techniques at the access network. In those scenarios, the 481 MR MUST test the CoA reachability following the Return Routability 482 procedure (this would involve only the CoTI/CoT), as specified in 483 [2]. 485 Once the CR has received and processed the BU message, it SHOULD send 486 a Binding Acknowledgement message to the MR. If no BA is received, 487 the MR MAY retransmit BU messages as long as some rate limitation is 488 applied. The MR MUST stop retransmitting when it receives a BA. 490 When an MR receives a BA message from a CR, the MR MUST validate the 491 message according to some tests. This needs further elaboration (TBD 492 in future versions of this document). Any BA not satisfying all of 493 those tests MUST be silently ignored. 495 When an MR receives a packet carrying a valid BA, the MR MUST examine 496 the Status field of the BA. If the status field indicates that the 497 BU was accepted, the MR MUST update the corresponding entry in its 498 Binding Update List to indicate that the Binding Update has been 499 acknowledged. The MR MUST then set up a bi-directional tunnel with 500 the IPv6 address of the CR as the other end-point of the tunnel, and 501 add the entries to its routing table required to make use of the 502 established tunnel in the forwarding of packets that match all of the 503 following rules: 504 o The IPv6 source address of the packet belongs to one of the IPv6 505 prefixes contained in the Mobile Network Prefix options included 506 in the BA message. Note that this implies that source address 507 based routing MAY be required in certain cases. 508 o The IPv6 destination address of the packet belongs to one of the 509 IPv6 prefixes contained in the Correspondent Router Prefix options 510 included in the BA message. 512 5. Correspondent Router operation 514 5.1. Conceptual Data Structures 516 Correspondent Routers MUST maintain a Binding Cache (BC) of bindings 517 with MRs. This BC is similar to the one kept by CNs with RO support 518 as defined in [2]. In addition to the fields contained in the BC 519 defined for a CN, the CR needs also to maintain the following 520 information: 522 o A flag specifying whether the entry is a Correspondent Router 523 entry or not (applicable only on nodes which support also MIPv6 524 RO, to differentiate from normal MIPv6 BCEs). 525 o Source IPv6 optimised prefix: this field contains the IPv6 526 address/prefix of those nodes managed by the CR (i.e. CNs) whose 527 traffic is being optimised by using an MR-CR bi-directional tunnel 528 with the MR. There could be multiple instances of this field in 529 the BCE. These are basically the IPv6 addresses/prefixes included 530 in the Correspondent Router Prefix options carried in the BU/BA 531 signalling exchanged by the CR and the MR. 532 o Destination IPv6 optimised prefix: this field contains the IPv6 533 address/prefix of those nodes (i.e. MNNs) whose traffic is being 534 optimised by using an MR-CR bi-directional tunnel with the MR. 535 There could be multiple instances of this field in the BCE. These 536 are basically the IPv6 addresses/prefixes included in the Mobile 537 Network Prefix options carried in the BU/BA signalling exchanged 538 by the CR and the MR. 539 o The CR MAY have a policy database that contains information 540 regarding which communications can be route optimised and which 541 not. It is up to the implementation the decision about the exact 542 content of this database, as well as if it can be dynamically 543 updated or it is pre-configured statically. 545 5.2. Correspondent Router Binding 547 When a CR receives a BU message from an MR, the CR MUST validate the 548 message according to some tests. This needs further elaboration (TBD 549 in future versions of this document). Any BU not satisfying all of 550 those tests MUST be silently ignored. Additionally, some other test 551 MUST be performed (such as authorisation check, etc.). If some of 552 these tests fail, the CR SHOULD return a BA to the MR including an 553 appropriate value in the Status field (TBD). 555 When a CR receives a packet carrying a valid BU, and all the tests 556 are successful, the CR SHOULD add an entry on its BC and return a BA 557 to the MR, setting the Status field to a value indicating success. 558 This BA would also include all the Mobile Network Prefix and 559 Correspondent Router Prefix Options included in the BU message. The 560 CR MUST then set up a bi-directional tunnel with the MR's CoA as the 561 other end-point of the tunnel, and add the entries in its routing 562 table required to make use of this tunnel in the forwarding of 563 packets that match all of the following rules: 564 o The IPv6 source address of the packet belongs to the one of the 565 IPv6 prefixes contained in the Correspondent Router Prefix options 566 contained in the BA message. Note that this implies that source 567 address based routing MAY be required in certain cases. 568 o The IPv6 destination address of the packet belongs to the one of 569 the IPv6 prefixes contained in the Mobile Network Prefix options 570 included in the BA message. 572 5.3. Intercepting Packets from a Correspondent Node 574 A Correspondent Router needs to intercept packets sent by all CNs 575 from which it has a BCE, since the CR has to send those packets 576 through the established MR-CR bi-directional tunnel. However, 577 depending on the topological location of the CR, different operation 578 may be needed in order to intercept packets from CNs. 580 If the CR is the gateway of all the CNs it manages -- that is, it is 581 always on the path between all CNs and any other node outside the 582 domain --, nothing needs to be done in order to intercept packets 583 that have to be route optimised, since all packets are already 584 received by the CR. 586 If the CR is not the gateway of all the CNs, in order to intercept 587 those packets that need to be route optimised, the CR MUST inject 588 routes advertising the corresponding MNPs within the domain of the 589 CR. This would make routers in the domain to forward the packets 590 addressed to those MNPs to the CR, so it can forward them to the 591 right MRs using the established MR-CN bi-directional tunnel. Further 592 attention is needed in order to come up with a flexible mechanism to 593 enable a CR in a domain receive only those packets that need to be 594 route optimised, without impacting on the routing of the rest of the 595 packets -- that should follow the normal route (towards the 596 respective home networks) --. Mechanisms enabling that behaviour are 597 subject of future versions of this document. 599 6. Security Considerations 601 CRON assumes that trust relationships exist between the MR/HA and the 602 CR, allowing IPsec/IKE to be used to secure Binding Updates. 603 Certificates are used to prove ownership of prefixes by MRs and CRs. 604 The Return Routability mechanism is used by the MR to prove CoA 605 ownership to the CR. 607 Given that CRON enables to change routing state at certain nodes, a 608 more detailed security analysis is needed (TBD in a future version of 609 this document). 611 7. IANA Considerations 613 This document requires IANA to assign a number for a new Mobility 614 Option type (Correspondent Router Prefix). 616 8. Acknowledgements 618 This draft collects input from many previous works. The concept of 619 Correspondent Router is known since at least 2002. Authors of the 620 present document therefore would like to thank and acknowledge 621 authors of these previous works. 623 The work of Carlos J. Bernardos and Maria Calderon has been also 624 partly supported by the Spanish Government under the POSEIDON 625 (TSI2006-12507-C03-01) project. 627 9. References 628 9.1. Normative References 630 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 631 Levels", BCP 14, RFC 2119, March 1997. 633 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 634 IPv6", RFC 3775, June 2004. 636 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 637 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 638 January 2005. 640 [4] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 641 "Multiple Care-of Addresses Registration", 642 draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. 644 9.2. Informative References 646 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 647 RFC 3753, June 2004. 649 [6] Ernst, T. and H-Y. Lach, "Network Mobility Support 650 Terminology", RFC 4885, July 2007. 652 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 653 RFC 4886, July 2007. 655 [8] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 656 Route Optimization Problem Statement", RFC 4888, July 2007. 658 [9] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 659 Route Optimization Solution Space Analysis", RFC 4889, 660 July 2007. 662 [10] Zhao, F., "NEMO Route Optimization Problem Statement and 663 Analysis", draft-zhao-nemo-ro-ps-01 (work in progress), 664 February 2005. 666 [11] Thubert, P., Molteni, M., and C. Ng, "Taxonomy of Route 667 Optimization models in the Nemo Context", 668 draft-thubert-nemo-ro-taxonomy-04 (work in progress), 669 February 2005. 671 [12] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", 672 draft-wakikawa-nemo-orc-01 (work in progress), November 2004. 674 [13] Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization 675 Requirements for Operational Use in Aeronautics and Space 676 Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02 677 (work in progress), May 2008. 679 [14] Baldessari, R., Ernst, T., and M. Lenardi, "Automotive Industry 680 Requirements for NEMO Route Optimization", 681 draft-ietf-mext-nemo-ro-automotive-req-00 (work in progress), 682 February 2008. 684 [15] Ng, C., Hirano, J., Petrescu, A., and E. Paik, "Consumer 685 Electronics Requirements for Network Mobility Route 686 Optimization", draft-ng-nemo-ce-req-02 (work in progress), 687 February 2008. 689 [16] Bauer, C. and S. Ayaz, "ATN Topology Considerations for 690 Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00 (work 691 in progress), July 2008. 693 [17] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 694 Multihoming in Network Mobility Support", RFC 4980, 695 October 2007. 697 [18] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair 698 Exploration Protocol for IPv6 Multihoming", 699 draft-ietf-shim6-failure-detection-13 (work in progress), 700 June 2008. 702 [19] Bernardos, C., Soto, I., Calderon, M., Boavida, F., and A. 703 Azcorra, "VARON: Vehicular Ad-hoc Route Optimisation for 704 NEMOO", Computer Communications, Volume 30, Issue 8, Pages 705 1765-1784 , June 2007. 707 Appendix A. Analysis of CRON and the Aeronautics requirements 709 This appendix looks at the Aeronautics requirements described in [13] 710 and analyses how CRON fits each of them. If a certain requirement 711 cannot be fulfilled by CRON as it is described in this document, 712 possible modifications/extensions are also considered. This analysis 713 aims at understanding if a CR-based solution could be a good 714 candidate to be used as a NEMO RO solution for the aeronautics 715 scenario. 717 A.1. Req1 - Separability 719 This requirement basically states that "an RO scheme MUST support 720 configuration by a per-domain dynamic RO policy database. Entries in 721 this database can be similar to those used in IPsec security policy 722 databases in order to specify either bypassing or utilizing RO for 723 specific flows". 725 This requirement is fulfilled by CRON, since the Route Optimisation 726 can be performed on an MNN-CN basis (MNP-CN prefix optimisations can 727 also be performed) and the decision about which communications are 728 optimised is taken by the MR. Therefore, different approaches can be 729 implemented in the MR (it is open to the particular CRON 730 implementation how to do it) to take this decision: static and 731 dynamic policies (using a protocol to update MR's policies), 732 decisions based on current load of the MR, etc. 734 A.2. Req2 - Multihoming 736 This requirement states that "an RO solution MUST support an MR 737 having multiple interfaces, and MUST allow a given domain to be bound 738 to a specific interface. It MUST be possible to use different MNPs 739 for different domains". 741 Since CRON achieves the NEMO RO by performing bindings with different 742 CRs, setting up bi-directional tunnels between a CR and an MR's CoA, 743 it is possible to support multi-interfaced MRs and use different MNPs 744 for different domains. Besides, CRON can potentially benefit 745 directly from any mechanism developed for MIPv6 to support multiple 746 interfaces (such as [4]). 748 We should also mention that although CRON can benefit from 749 multihoming solutions developed within the MEXT WG, multihoming 750 issues in Network Mobility [17] should be tackled specifically by a 751 general NEMO multihoming framework. Since CRON does not modify in 752 any way the NEMO Basic Support operation, it will also be compatible 753 with such a general NEMO multihoming solution. 755 A.3. Req3 - Latency 757 This requirement says: "while an RO solution is in the process of 758 setting up or reconfiguring, packets of specified flows MUST be 759 capable of using the MRHA tunnel". 761 This means that an RO solution MUST NOT prevent data packets from 762 being forwarded through the MRHA bi-directional tunnel while the 763 required RO operations are being performed. This requirement is also 764 fulfilled by CRON, since while the MR performs all the required 765 signalling (i.e. CoTI/CoT and BU/BA), communications aimed at be 766 route optimised still use the MRHA tunnel. 768 A.4. Req4 - Availability 770 This requirement states that "an RO solution MUST be compatible with 771 network redundancy mechanisms and MUST NOT prevent fall-back to the 772 MRHA tunnel if an element in an optimized path fails". It is also 773 stated that "an RO mechanism MUST NOT add any new single point of 774 failure for communications in general". 776 On the one hand, current NEMO Basic Support protocol [3] does not 777 fulfil that today, and therefore needs additional work to be carried- 778 out. On the other hand, CRON brings the role of the Correspondent 779 Router into the picture. Therefore, a new potential point of failure 780 is added: the CR. 782 If a CR fails, communications being optimised would obviously be 783 disrupted. Although CRON currently does not address this issue, 784 additional mechanisms -- such as deploying several redundant or back- 785 to-back CRs, or designing/reusing existing protocols to keep the RO 786 state of several CRs synchronised -- might be used here. In any 787 case, by using short lifetimes, the potential negative effect of such 788 a CR failure may be reduced. Besides, protocols such as REAP [18] 789 can be used to effectively detect failures between the MR and the CR 790 (not only caused by a CR failure, but also by a problem on the path 791 between them). 793 In case an MR fails, if it is the only one deployed at the NEMO, this 794 would obviously disrupt established connections. In the case of a 795 multiple-MR NEMO, additional mechanisms would be required in order to 796 guarantee that route optimised communications managed by a particular 797 MR would survive in case this MR fails. Again, although CRON 798 currently does not address this issue, additional mechanisms -- such 799 as deploying back-to-back MRs in aircrafts or designing/reusing 800 existing protocols to keep the RO state of several MRs synchronised 801 -- might be used here. 803 A.5. Req5 - Packet Loss 805 This requirement says that "an RO scheme SHOULD NOT cause either loss 806 or duplication of data packets during RO path establishment, usage, 807 or transition, above that caused in the NEMO basic support case. An 808 RO scheme MUST NOT itself create non-transient losses and 809 duplications within a packet stream". 811 The use of CRON does not add any significant delay nor causes any 812 additional packet loss compared to the normal NEMO Basic Support 813 protocol handover. It is worth to mention that some signalling is 814 required to update the bindings at the CRs, and although this can be 815 done in parallel with the Home Registration, a small delay can be 816 introduced because of this. Micro-mobility techniques can be used if 817 required to mitigate that effect, if required. 819 A.6. Req6 - Scalability 821 This requirement says that "an RO scheme MUST be simultaneously 822 usable by the MNNs on hundreds of thousands of craft without 823 overloading the ground network or routing system. This explicitly 824 forbids injection of BGP routes into the global Internet for purposes 825 of RO". 827 There are different aspects that may affect to the scalability of 828 CRON: 830 o Memory consumption at the MR. CRON needs some additional 831 information to be stored at the MR, such extended BUL. The 832 required memory to store this extended BUL is relatively small and 833 grows linearly with the number of different route optimised 834 communications. 835 o Processing load at the MR. CRON requires more complex routing 836 operations at the MR. The routing table of an MR performing RO 837 operations would have more entries than a normal RFC 3963 MR, the 838 MR should set-up and maintain more bi-directional tunnels, and 839 source address based routing might be required. However, all of 840 these operations do not add significant load, and in any case 841 complexity grows linearly with the number of different route 842 optimised communications. 843 o Processing load and memory consumption at the CR. The same 844 reasoning applies here. Besides, multiple CRs can be deployed on 845 sites supporting a high load of route optimised traffic. 846 o Impact on the global routing system. CRON does not have any 847 impact on the global routing tables, and therefore it does not 848 introduce any routing scalability issue, even with large 849 deployments. 851 A.7. Req7 - Efficient Signaling 853 This requirement is related to the additional signalling required by 854 a NEMO RO solution, and basically states that "an RO scheme MUST be 855 capable of efficient signaling in terms of both size and number of 856 individual signaling messages and the ensemble of signaling messages 857 that may simultaneously be triggered by concurrent flows". 859 With CRON, the amount of required signalling depends on the number 860 and type of communications that are optimised. Since almost any 861 granularity is supported by CRON, in those cases in which individual 862 MNN-CN optimisations are not required -- and MNP-CN prefix ones are 863 used instead -- the amount of signalling needed is very small. In 864 order to perform an optimisation (generally speaking, a MNP-CN prefix 865 optimisation), a BU/BA message exchange is required (plus probably a 866 CoTI/CoT exchange to test MR's CoA reachability). 868 A.8. Req8 - Security 870 This requirement is different depending on the considered traffic 871 domain. For ATS/AOS domains, there are three sub-requirements: "a) 872 The RO scheme MUST NOT further expose MNPs on the wireless link than 873 already is the case for NEMO basic support; b) The RO scheme MUST 874 permit the receiver of a BU to validate an MR's ownership of the CoAs 875 claimed by an MR; and c) The RO scheme MUST ensure that only 876 explicitly authorized MRs are able to perform a binding update for a 877 specific MNP". For the PIES domain: "there are no additional 878 requirements beyond those of normal Internet services and the same 879 requirements for normal Mobile IPv6 RO apply". 881 CRON meets all aforementioned requirements. a) Since BU/BA signalling 882 is sent protected with IPsec, MNPs are not exposed, b) the MR's CoA 883 ownership can be tested by means of the RR procedure (in particular, 884 by means of the CoTI/CoT exchange), and c) by the use of certificates 885 and local policies, only authorised MRs can perform a binding for a 886 specific MNP. 888 A.9. Req9 - Adaptability 890 This requirement states that "applications using new transport 891 protocols, IPsec, or new IP options MUST be possible within an RO 892 scheme". 894 Since CRON makes use of a bi-directional tunnel between the MR and 895 the CR, encapsulating data packets into the tunnel -- without 896 performing any modifications to them --, this requirement is also 897 met. 899 A.10. Des1 - Configuration 901 This requirement is not considered as a strict one, and basically 902 states that "it is desirable that a NEMO RO solution be as simple to 903 configure as possible and also easy to automatically disable if an 904 undesirable state is reached". 906 CRON configuration is not detailed in this document, since it is open 907 to implementation. However, even if complex policies are used to 908 determine which communication are route optimised, CRON configuration 909 would be as simple as configuring today's firewalls. Some 910 coordination is needed though to configure properly MRs, CRs -- and 911 likely additional infrastructure (such as CR-resolvers) -- in order 912 to effectively enable RO to take place. 914 A.11. Des2 - Nesting 916 This requirement is not considered as a strict one, and basically 917 states that "it is desirable if the RO mechanism supports RO for 918 nested MRs". 920 CRON, as it is described in this document, does not provide RO 921 capabilities for nested MRs. 923 A.12. Des3 - System Impact 925 This requirement is not considered as a strict one, and basically 926 states that "low complexity in systems engineering and configuration 927 management is desirable in building and maintaining systems using the 928 RO mechanism". 930 CRON requires changes on the MR, and the deployment of additional 931 entities: the CRs (although this might be done by simply updating the 932 software of some existing routers at the CN domains to support the CR 933 functionality). The deployment of CRON also requires trust 934 relationships between MRs/HAs and CRs to be in place. In order to 935 help MRs in the discovery of CRs, the deployment of external 936 services, such as CR-resolvers, might be required. 938 A.13. Des4 - VMN Support 940 This requirement is not considered as a strict one, and basically 941 states that "it is strongly desirable for VMNs to be supported by the 942 RO technique, but not strictly required". 944 CRON is aimed at bypassing the MR's HA, but it does not avoid the 945 traversal of VMNs' HAs. Therefore, a completely optimal path is not 946 follow by packets of VMNs (only the MR's HA is bypassed). 948 A.14. Des5 - Generality 950 This requirement is not considered as a strict one, and basically 951 states that "an RO mechanism that is "general purpose", in that it is 952 also readily usable in other contexts outside of aeronautics and 953 space exploration, is desirable". 955 Correspondent Router approaches were designed as general NEMO RO 956 frameworks, not being focused to address any particular scenario. 957 Current CRON design has been tailored to address the particular 958 scenario of aeronautics and space exploration. However, CRON -- with 959 or without modifications/extensions -- could also be considered as a 960 solution for other scenarios such as the vehicular [14] one. 961 Besides, extensions to enable the use of CRON without the requiring 962 the deployment of certificates -- using techniques similar to the 963 ones described in [19] -- are currently being analysed and will be 964 included in future revisions of this document. These extensions 965 would enable extending the applicability of CRON to other scenarios 966 such as the consumer electronics one [15]. 968 Authors' Addresses 970 Carlos J. Bernardos 971 Universidad Carlos III de Madrid 972 Av. Universidad, 30 973 Leganes, Madrid 28911 974 Spain 976 Phone: +34 91624 6236 977 Email: cjbc@it.uc3m.es 979 Maria Calderon 980 Universidad Carlos III de Madrid 981 Av. Universidad, 30 982 Leganes, Madrid 28911 983 Spain 985 Phone: +34 91624 8780 986 Email: maria@it.uc3m.es 988 Ignacio Soto 989 Universidad Carlos III de Madrid 990 Av. Universidad, 30 991 Leganes, Madrid 28911 992 Spain 994 Phone: +34 91624 5974 995 Email: isoto@it.uc3m.es 997 Full Copyright Statement 999 Copyright (C) The IETF Trust (2008). 1001 This document is subject to the rights, licenses and restrictions 1002 contained in BCP 78, and except as set forth therein, the authors 1003 retain all their rights. 1005 This document and the information contained herein are provided on an 1006 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1007 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1008 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1009 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1010 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1011 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1013 Intellectual Property 1015 The IETF takes no position regarding the validity or scope of any 1016 Intellectual Property Rights or other rights that might be claimed to 1017 pertain to the implementation or use of the technology described in 1018 this document or the extent to which any license under such rights 1019 might or might not be available; nor does it represent that it has 1020 made any independent effort to identify any such rights. Information 1021 on the procedures with respect to rights in RFC documents can be 1022 found in BCP 78 and BCP 79. 1024 Copies of IPR disclosures made to the IETF Secretariat and any 1025 assurances of licenses to be made available, or the result of an 1026 attempt made to obtain a general license or permission for the use of 1027 such proprietary rights by implementers or users of this 1028 specification can be obtained from the IETF on-line IPR repository at 1029 http://www.ietf.org/ipr. 1031 The IETF invites any interested party to bring to its attention any 1032 copyrights, patents or patent applications, or other proprietary 1033 rights that may cover technology that may be required to implement 1034 this standard. Please address the information to the IETF at 1035 ietf-ipr@ietf.org.