idnits 2.17.1 draft-haddad-mip6-tunneling-optimization-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 528. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 9, 2007) is 6135 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-mipshop-4140bis-00 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility for IPv6 (MIP6) WG W. Haddad 3 Internet-Draft M. Naslund 4 Expires: January 10, 2008 Ericsson Research 5 P. Nikander 6 Ericsson Research Nomadic Lab 7 July 9, 2007 9 IP Tunneling Optimization in a Mobile Environment 10 draft-haddad-mip6-tunneling-optimization-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This memo introduces a simple tunneling optimization mechanism, which 44 removes the need for inserting an additional header in the IP packet. 45 The main goals are to minimize the packet size, provide a simpler 46 protocol design and a better efficiency. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions used in this document . . . . . . . . . . . . . . 4 52 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Tunneling Optimization for BT mode and HMIPv6 . . . . . . . . 7 54 5. Tunneling Optimization for RO mode . . . . . . . . . . . . . . 11 55 6. Tunneling Optimization for DSMIPv6 . . . . . . . . . . . . . . 12 56 7. Bit and Options Formats . . . . . . . . . . . . . . . . . . . 13 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 60 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 61 10.2. Informative References . . . . . . . . . . . . . . . . . 16 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 63 Intellectual Property and Copyright Statements . . . . . . . . . . 18 65 1. Introduction 67 IP tunneling is a mechanism widely used for different purposes. For 68 example, it enables relying on a dedicated third party to modify the 69 IP packet header, in order to re-route the packets to their new 70 destination. This is mainly the case in a mobile environment where 71 IP tunneling is used in most protocols. In fact, the mobile IPv6 72 bidirectional tunneling (BT) mode described in [MIPv6]) uses IP 73 tunneling to route data through the home agent (HA). The same 74 mechanism is applied between the mobility anchor point (MAP) and the 75 mobile node (MN) in the hierarchical mobile IPv6 (HMIPv6) protocol 76 (described in [HMIPv6]). A modified IP tunneling version is also 77 used in MIPv6 route optimization (RO) mode. 79 This memo introduces a simple tunneling optimization (TO) mechanism, 80 which virtualizes the IP tunnel concept often used in traffic 81 exchange. TO mechanism is based on securely exchanging a "pad 82 translator" (PaT) between both sides of the (supposed) tunnel. 83 The PaT main role is to translate incoming/outgoing packet header to 84 another one before injecting it inside/outside the tunnel. TO main 85 goals include a reduced packet size, a simpler protocol design and a 86 better efficiency. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [TERM]. 94 3. Motivation 96 The motivation behind this work is the widespread use of different 97 forms of IP tunneling mechanisms in mobile environment and their 98 negative impact on the protocol efficiency as translated in the data 99 packet size, bandwidth usage and battery power consumption. 101 In the following, we consider IPv6 mobility protocols only and start 102 with a brief description of the IP tunneling mechanism used in both 103 MIPv6 BT mode and HMIPv6 protocol. Next, we describe the MIPv6 RO 104 mode tunneling mechanism, then show in the next section how the TO 105 mechanism completely eliminates the need for IP tunneling in these 106 mobility protocols in a simple and elegant way. 107 Other mobility related protocols, e.g., Fast MIPv6 described in 108 [FMIPv6] and the ongoing work on proxy MIPv6 ([PMIPv6]) can also 109 benefit from using TO mechanism, especially when the path between 110 access routers (ARs) and/or between the HA and a PMIPv6 node(s) 111 includes a wireless medium. 113 A closer look on the tunneling mechanism used in the BT mode (i.e., 114 between the HA and the MN) and HMIPv6 protocol (i.e., between the MAP 115 and the MN) highlights different issues that need to be addressed. A 116 first one is the expansion of the packet size due to the addition of 117 a new IP header. In the two protocols, such expansion is mainly 118 equal to two IP addresses. This means that the MN has to send at 119 least an additional 256 bits each time it transmits a data packet to 120 the CN. The impact of such addition is very significant on the 121 battery life. In fact, it has been shown in [EALDC] that wireless 122 transmission of a single bit can require over 1000 times more energy 123 than a single 32-bit computation. 124 Consequently, it would be more beneficial for the MN to avoid 125 transmitting extra bits over the air interface in exchange for some 126 additional computation only. 128 A second issue is the impact of packet size on the available 129 bandwidth. In fact, as wireless bandwidths have gained the solid 130 reputation of being always scarce, it would be of great importance to 131 monitor carefully how they are managed, especially when real time 132 multimedia applications are introduced on a larger scale. 133 Consequently, eliminating the extra bits added to each IP packet 134 header would also be highly beneficial for the network access 135 provider. 137 A third issue is related to privacy aspects. In fact, when 138 exchanging data traffic with the HA, the MN has to include its IPv6 139 home address (HoA) in each data packet sent to the HA, in addition to 140 its care-of address (CoA) (or its regional care-of address (RCoA) 141 when sending data packets to the MAP in addition to the on-link CoA 142 (LCoA)). Similarly, the HA has to disclose the MN's HoA and CoA in 143 each data packet sent to the MN (or the RCoA and LCoA in each data 144 packet sent by the MAP to the MN). It follows that having the two 145 MN's addresses disclosed in the same data packet enables a malicious 146 node located on path between the MN and the HA or between the MN and 147 the MAP to easily identify, link and trace the MN's movements. Note 148 that the MN's privacy can be better protected if the traffic is 149 encrypted, which may not be always possible for various reasons. 151 When the RO mode is used, the tunneling mechanism applied between the 152 MN and the CN differs from the one used in the BT mode and HMIPv6 153 protocol in the fact that it adds only one additional IP address, 154 i.e., the MN's HoA, in each data packet exchanged between the two 155 endpoints. This means that each data packet sent/received by the MN 156 MUST carry three IP addresses instead of four: the MN's CoA, the CN's 157 address and the MN's HoA. For this purpose, the MN uses a Home 158 Address Option (HAO) to carry its HoA in each data packet sent to the 159 CN and the CN uses a Routing Header (RH) to carry the MN's HoA in 160 each data packet sent to the MN. The use of HAO and RH are in fact 161 degenerated tunnels as shown in [TUN]. This form of tunneling is 162 mandated as long as the MN's corresponding binding lifetime has not 163 expired. 164 The impact of the RO tunneling on the MN's privacy is the same as 165 described earlier in the BT mode and HMIPv6 protocol. The fact that 166 each data packet discloses the MN's HoA and CoA enables a malicious 167 node located on path between the two endpoints to identify, link and 168 trace the MN's movements across the Internet. 170 Note that using a PaT does not completely solve the privacy problem. 171 However, it offers a significant advantage in the fact that it 172 narrows the problem to the critical signaling messages, i.e., Binding 173 Update and Acknowledgment (BU/BA) in the case of BT and RO modes and 174 the Local BU (LBU) in the HMIPv6 case, where applying security 175 measures is not just an option. It follows that hiding/replacing the 176 HoA in and encrypting the PaT sent in the BU message are two measures 177 which can provide privacy protection for the MN against eavesdroppers 178 located on path between the MN and the CN/HA/MAP. 180 4. Tunneling Optimization for BT mode and HMIPv6 182 TO mechanism addresses tunneling issues described earlier by keeping 183 the original packet size unmodified and removing the need for an 184 additional IP header. 186 TO mechanism is based on using a PaT to easily translate IP packets 187 headers to new ones which reflect the topologies of the new chosen 188 origin and destination. We limit the scope of the PaT in this 189 document to IPv6 addresses only but it is important to note that its 190 usefulness can also be expanded to translate content(s) of other 191 particular field(s). Another way to describe the PaT functionality 192 is to consider it as a mechanism which virtualizes the need for 193 explicit tunneling. 195 In order to better describe the suggested mechanism, we apply it to 196 the BT mode and describes the different steps required between the MN 197 and the HA to implement it. In case of HMIPv6 protocol, we note that 198 the same approach can be applied but with HMIPv6 specific signaling 199 messages and IPv6 addresses. After that, we apply the suggested 200 mechanism in the RO mode. 202 The BT mode starts after the MN switches to a foreign network. In 203 this case, the MN configures a new CoA and notifies its HA by 204 securely exchanging a BU and BA messages. After creating the binding 205 between the two MN's addresses, both nodes start tunneling data 206 packets between them. From the MN side, IP tunneling is applied on 207 each data packet sent to the HA by attaching an outer IP header which 208 contains the MN's CoA as source address and the HA's IP address as 209 destination address. The inner IP header carries the MN's HoA as 210 source address and the CN's address as destination address. 211 On the HA side, IP tunneling is applied on incoming data packets 212 (i.e., sent by the CN to the MN's HoA) by attaching to each packet an 213 outer which carries the MN and the HA IP addresses i.e., the source 214 address becomes the HA's address and the destination address is the 215 MN's CoA. 217 The data packet tunneling format on the MN and HA sides is as 218 follows: 220 <-- outer IPv6 header -> <-- inner IPv6 header -> 221 +----+--------+--------+ +----+--------+--------+ +------------ 222 | | | | | | | | | 223 |oNAF| oSRC | oDEST | |iNAF| iSRC | iDEST | | iPAYLOAD 224 | | | | | | | | | 225 +----+--------+--------+ +----+--------+--------+ +------------ 227 where: 229 - NAF represents the non-address fields of an IPv6 header (I.e., the 230 first 8 octets of an IPv6 header) 232 - SRC is an IPv6 source address 234 - DEST is an IPv6 destination address 236 - EXT is zero or more IPv6 extension headers 238 - the prefix "o" means "outer" 240 In the HMIPv6 case, the MN attaches an outer header which contains 241 its LCoA as source address and the selected MAP's IP address as 242 destination address. The inner header contains the MN's RCoA as 243 source address and the CN's IP address as destination address. 244 Similarly, the MAP attaches an outer header to all data packets sent 245 by the CN to the MN's RCoA. The outer header is the same as the one 246 used by the MN but with the two addresses inverted. 248 The first step towards implementing the TO mechanism consists on 249 building the PaT at the MN's side. Since we limit the PaT 250 functionality in this document to the IP addresses only, the PaT will 251 consist on two different 128-bit translator parameters (TPs): 252 PaT = {TP_Source (TPS) , TP_Destination (TPD)} 254 In the BT mode, TPS and TPD are computed in the following way: 256 - TPS = oSrc_Addr XOR iSrc_Addr 258 Where: 259 - oSrc_Addr is the Outer header Source Address (CoA) 260 - iSrc_Addr is the Inner header Source Address (HoA) 262 - TPD = oDst_Addr XOR iDst_Addr 264 Where: 265 - oDst_Addr is the Outer header Destination Address (HA's IP address) 266 - iDst_Addr is the Inner header Destination Address (CN's IP address) 268 In HMIPv6 protocol, the PaT is computed in the same way as in the BT 269 mode but with using the appropriate IP addresses defined in HMIPv6: 271 - CoA = LCoA 272 - HoA = RCoA 273 - HA's IP address = MAP's IP address 275 The next step after building the PaT is to securely share it with the 276 HA or the MAP (i.e., HMIPv6 case). This is done by inserting the PaT 277 components in two new options (called PaT Source (PaTS) and PaT 278 Destination (PaTD)) carried by the BU message. The two options MUST 279 be sent encrypted. 280 Another way to share the PaT would consist on using the BU message 281 (e.g., by setting a new bit) to request the HA to build the PaT. In 282 such case, the MN has to send the CN's IP address(es) in the BU 283 message. For privacy purpose, the CN's address SHOULD be sent 284 encrypted. 286 It follows from the above description, that each time the MN 287 configures a new CoA, it has to build a new PaT and send it in a BU/ 288 LBU (i.e., with the new CoA/LCoA) to the HA/MAP. 290 If the MN is communicating with multiple CNs, then it SHOULD 291 configure one CoA per CN and build the corresponding PaT before 292 sending it to the HA. Such step is required in order to avoid any 293 confusion over which PaT to apply at the HA side on data packets sent 294 by the MN. The same requirement arises in the HMIPv6 case which 295 means that the MN has to configure one LCoA per CN, build the 296 corresponding PaT then send it to the MAP. 297 Consequently, the HA/MAP SHOULD create one entry in its BCE for each 298 MN's CoA/LCoA and SHOULD add the corresponding CN's IP address 299 together with the corresponding PaT. 301 Upon receiving a BU message carrying a PaT, the HA creates first a 302 binding between the two MN's addresses and stores them together with 303 the PaT in its binding cache entries (BCE) table. Then, the HA sends 304 back a BA message to the MN. 305 It follows that, when the MN has multiple CoAs, then the HA SHOULD 306 create one entry in its BCE for each MN's CoA and SHOULD add the 307 corresponding CN's IP address to the MN's addresses and the 308 corresponding PaT. 309 Similarly, in an HMIPv6 domain, the MN sends the PaT encrypted in the 310 LBU message to its MAP and waits for the BA message before applying 311 the PaT on data packets. 313 After creating the binding and sharing the PaT with the HA/MAP, the 314 MN applies it on each data packet sent to the CN (i.e., via the HA/ 315 MAP) and on each data packet received from the HA/MAP. The HA/MAP 316 applies the PaT on each data packet received from the MN before 317 sending it to the CN and on each data packet sent by the CN to the 318 MN's HoA/RCoA before sending it to the MN. 320 When the MN needs to send a data packet to the CN, it applies the PaT 321 on the IP header in the following way (Eq. 1): 323 - Src_Addr = iSrc_Addr XOR TPS 324 - Dst_Addr = iDst_Addr XOR TPD 325 Where Src_Addr is the source address disclosed in the IP header and 326 Dst_Addr is the destination address used in the IP header. It 327 becomes obvious at this stage that the Src_Addr is the MN's CoA (or 328 LCoA in HMIPv6) and the Dst_Addr is the HA's IP address (or MAP's IP 329 address in HMIPv6). 331 When the HA/MAP receives a data packet from the MN, it retrieves the 332 corresponding PaT on the IP header and translates the IP addresses to 333 new ones. Since the PaT used by the HA is the same as the one used 334 by the MN and the required operation is only a XOR, then the 335 resulting IP addresses are the ones used as iSrc_Addr and iDst_Addr 336 in (Eq. 1). This means: 338 - nSrc_Addr = Src_Addr XOR TPS (= iSrc_Addr) 339 - nDst_Addr = Dst_Addr XOR TPD (= iDst_Addr) 341 Where the nSrc_Addr is the new IP source address and nDst_Addr is the 342 new IP destination address used in the data packet sent by the HA to 343 the CN. 345 Similarly, when the CN sends a data packet to the MN's HoA, the HA/ 346 MAP applies the MN's corresponding PaT to the IP packet header and 347 translates the two IP addresses to new ones before sending the data 348 packet to the MN. 350 Finally, when the MN gets a data packet from its HA/MAP, it checks 351 first if the data packet is encapsulated or not. In the latter case, 352 the MN applies the PaT to the IP packet header. Otherwise, the MN 353 follows the BT mode to process the packet. 354 Note that in the current design, the HA SHOULD always tunnel any new 355 data packet sent by a new CN according to the BT mode rules and 356 SHOULD NOT apply any PaT until it receives one from the MN. However, 357 further optimizations are possible and will be introduced in future 358 version of this document. 360 5. Tunneling Optimization for RO mode 362 As mentioned earlier, MIPv6 RO mode uses a different form of IP 363 tunnel between the two endpoints (i.e., MN and CN) than the one used 364 in the BT mode (i.e., between the MN and its HA). The modified IP 365 tunnel discloses three IP addresses to the receiver and is used by 366 both sides when exchanging data packets. Consequently, the TO 367 mechanism requires a slight modification in order to adapt it to the 368 degenerated tunnel used in the RO mode. 370 For this purpose, when the RO mode is used, the PaT components SHOULD 371 be computed by both endpoints in the following way: 373 - TPS = CoA XOR HoA 374 - TPD = 0000:0000:0000:0000:0000:0000:0000:0000 376 Where the CoA and HoA are the MN's IP addresses. Note that when the 377 RO mode is used, the MN does not need to send the PaT in the BU 378 message since the CN can build it. However, the MN SHOULD send an 379 explicit request to the CN to check if both endpoints can use the PaT 380 when exchanging data packets. For this purpose, the request consists 381 on setting a new bit in the BU message sent by the MN to the CN and 382 getting an explicit acknowledgment to the request from the CN in the 383 BA message. If the CN is able to use the PaT, then it SHOULD set a 384 new bit in the BA message. Otherwise, it can only send the BA 385 message without any further action. 387 It follows from the above, that each time the MN needs to send a data 388 packet to the CN following the RO mode rules, it SHOULD apply the PaT 389 to the IP packet header in order to translate it to the right IP 390 address, i.e., the MN's CoA. The same rule applies when receiving a 391 data packet from the CN (i.e., sent to the MN's CoA). On the CN 392 side, the PaT is applied each time a data packet needs to be sent to 393 the MN or each time a data packet is received from the MN. 395 It should be noted that when the RO mode is in use, the PaT can be 396 applied only as long as the MN's CoA binding lifetime has not 397 expired. In addition, the MN SHOULD set the PaT bit in each BU 398 message sent to the CN as long as it prefers to use the TO mechanism 399 during the ongoing session. This also means that a new PaT needs to 400 be built after each BU message carrying a new CoA. 402 6. Tunneling Optimization for DSMIPv6 404 TBD 406 7. Bit and Options Formats 408 TBD 410 8. Security Considerations 412 This memo describes a TO mechanism which is mainly used to avoid 413 explicit IP tunneling in mobility protocols. 415 The proposed mechanism enhances the MN's privacy by removing the need 416 to disclose the MN's two IP addresses in the same data packet. 417 Consequently, it simplifies and narrows the privacy problem in a 418 mobile environment. 420 In the current memo, the PaT is only applied on the IPv6 addresses 421 and as such it does not create nor amplify any new or existing 422 threats. 424 9. Acknowledgments 426 The authors would like to thank Laurent Marchand, Conny Larsson, 427 Shinta Sugimoto, Suresh Krishnan, Hesham Soliman and George Tsirtsis 428 for their valuable comments. 430 10. References 432 10.1. Normative References 434 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 435 for IPv6", RFC 3775, June 2004. 437 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 438 Requirement Levels", RFC 2119, BCP , March 1997. 440 10.2. Informative References 442 [EALDC] Barr, K. and K. Asanovic, "Energy-Aware Lossless Data 443 Compression", ACM Transactions Computer Systems, 444 August 2006. 446 [FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", Internet 447 Draft, draft-koodli-mipshop-rfc4068bis-00.txt, March 2007. 449 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 450 "Hierarchical Mobile IPv6", Internet 451 Draft, draft-ietf-mipshop-4140bis-00.txt, March 2007. 453 [PMIPv6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 454 and B. Patil, "Proxy Mobile IPv6", Internet 455 Draft, draft-ietf-netlmm-proxymip6-01.txt, June 2007. 457 [TUN] Deering, S. and B. Zill, "Redundant Address Deletion when 458 Encapsulating IPv6 in IPv6", Internet 459 Draft, draft-deering-ipv6-encap-addr-deletion-00.txt, 460 November 2001. 462 Authors' Addresses 464 Wassim Haddad 465 Ericsson Research 466 Torshamnsgatan 23 467 SE-164 80 Stockholm 468 Sweden 470 Phone: +46 8 4044079 471 Email: Wassim.Haddad@ericsson.com 473 Mats Naslund 474 Ericsson Research 475 Torshamnsgatan 23 476 SE-164 80 Stockholm 477 Sweden 479 Phone: +46 8 58533739 480 Email: Mats.Naslund@ericsson.com 482 Pekka Nikander 483 Ericsson Research Nomadic Lab 484 Jorvas FI-02420 485 Finland 487 Phone: +358 9 299 1 488 Email: Pekka.Nikander@nomadiclab.com 490 Full Copyright Statement 492 Copyright (C) The IETF Trust (2007). 494 This document is subject to the rights, licenses and restrictions 495 contained in BCP 78, and except as set forth therein, the authors 496 retain all their rights. 498 This document and the information contained herein are provided on an 499 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 500 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 501 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 502 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 503 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 504 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 506 Intellectual Property 508 The IETF takes no position regarding the validity or scope of any 509 Intellectual Property Rights or other rights that might be claimed to 510 pertain to the implementation or use of the technology described in 511 this document or the extent to which any license under such rights 512 might or might not be available; nor does it represent that it has 513 made any independent effort to identify any such rights. Information 514 on the procedures with respect to rights in RFC documents can be 515 found in BCP 78 and BCP 79. 517 Copies of IPR disclosures made to the IETF Secretariat and any 518 assurances of licenses to be made available, or the result of an 519 attempt made to obtain a general license or permission for the use of 520 such proprietary rights by implementers or users of this 521 specification can be obtained from the IETF on-line IPR repository at 522 http://www.ietf.org/ipr. 524 The IETF invites any interested party to bring to its attention any 525 copyrights, patents or patent applications, or other proprietary 526 rights that may cover technology that may be required to implement 527 this standard. Please address the information to the IETF at 528 ietf-ipr@ietf.org. 530 Acknowledgment 532 Funding for the RFC Editor function is provided by the IETF 533 Administrative Support Activity (IASA).