idnits 2.17.1 draft-ietf-mip4-mobike-connectivity-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 520. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 22, 2006) is 6668 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) -- Looks like a reference, but probably isn't: 'MVPN' on line 205 -- Looks like a reference, but probably isn't: 'R' on line 215 -- Looks like a reference, but probably isn't: 'DHCP' on line 215 == Unused Reference: '11' is defined on line 470, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. '2') (Obsoleted by RFC 5944) == Outdated reference: A later version (-08) exists of draft-ietf-mobike-protocol-07 ** Obsolete normative reference: RFC 4306 (ref. '4') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 2409 (ref. '6') (Obsoleted by RFC 4306) == Outdated reference: A later version (-05) exists of draft-ietf-mip4-vpn-problem-solution-02 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group V. Devarapalli 3 Internet-Draft P. Eronen 4 Expires: July 26, 2006 Nokia 5 January 22, 2006 7 Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE 8 draft-ietf-mip4-mobike-connectivity-00 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 July 26, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Enterprise users require mobility and secure connectivity when they 42 roam and connect to the services offered in the enterprise. Secure 43 connectivity is required when the user connects to the enterprise 44 from an untrusted network. Mobility is beneficial when the user 45 moves, either inside or outside the enterprise network, and acquires 46 a new IP address. This document describes a solution using Mobile 47 IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure 48 connectivity and mobility. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Access modes . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1.1. Access mode: 'c' . . . . . . . . . . . . . . . . . . . 6 57 3.1.2. Access mode: 'f' . . . . . . . . . . . . . . . . . . . 6 58 3.1.3. Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7 59 3.2. Mobility within the enterprise . . . . . . . . . . . . . . 7 60 3.3. Mobility when outside the enterprise . . . . . . . . . . . 7 61 3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 8 62 3.4.1. Operation when moving from an untrusted network . . . 8 63 3.4.2. Operation when moving from a trusted network . . . . . 9 64 4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 72 Intellectual Property and Copyright Statements . . . . . . . . . . 13 74 1. Introduction 76 A typical enterprise network consists of users connecting to the 77 services from a trusted network (intranet), and from an untrusted 78 network (Internet). The trusted and untrusted networks are typically 79 separated by a demilitarized zone (DMZ). Access to the intranet is 80 controlled by a firewall and a VPN gateway in the DMZ. 82 Enterprise users, when roaming on untrusted networks, most often have 83 to authenticate themselves to the VPN gateway and set up a secure 84 tunnel in order to access the intranet. The use of IPsec VPNs is 85 very common to enable such secure connectivity to the intranet. When 86 the user is on the trusted network, VPNs are not used. However, the 87 users benefit tremendously when session mobility between subnets, 88 through the use of Mobile IPv4, is available. 90 There has been some work done on using Mobile IPv4 and IPsec VPNs to 91 provide roaming and secure connectivity to an enterprise [10]. The 92 solution described in [10] was designed with certain restrictions, 93 including requiring no modifications to the VPN gateways and involves 94 the use of two layers of MIPv4, with one home agent inside the 95 intranet and one in the Internet or in the DMZ before the VPN 96 gateway. The per-packet overhead is very high in this solution. It 97 is also challenging to implement and have two instances of MIPv4 98 active at the same time on a mobile node. However, the solution 99 described here is only applicable when IKEv2 IPsec VPNs are used. 101 This document describes an alternate solution that does not require 102 two layers of MIPv4. The solution described in this document uses 103 Mobile IPv4 when the mobile node is on the trusted network and MOBIKE 104 capable IPsec VPNs when mobile node is on the untrusted network. The 105 mobile node uses the tunnel inner address (TIA) given out by the 106 IPsec VPN gateway as the co-located CoA for MIPv4 registration. This 107 eliminates the need for using an external MIPv4 home agent and the 108 need for encapsulating the VPN tunnel inside a MIPv4 tunnel. 110 The following assumptions are made for the solution described in this 111 document. 113 o IKEv2 [4] and IPsec [5] are used to set up the VPN tunnels between 114 the mobile node and the VPN gateway. 115 o The VPN gateway and the mobile node support MOBIKE extensions as 116 defined in [3]. 117 o When the mobile node is on the trusted network, traffic should not 118 go through the DMZ. Current deployments of firewalls and DMZs 119 consider the scenario where only a small amount of the total 120 enterprise traffic goes through the DMZ. Routing through the DMZ 121 typically involves stateful inspection of each packet by the 122 firewalls in the DMZ. 123 o When the mobile node is on the trusted network and uses a wireless 124 access technology, confidentiality protection of the data traffic 125 is provided by the particular access technology. In some 126 networks, confidentiality protection MAY be available between the 127 mobile node and the first hop access router, in which case it is 128 not required at layer 2. 130 Mobility extensions for IKEv2 are being standardized. There is no 131 similar effort for IKEv1 [6]. 133 This document also presents a solution for the mobile node to detect 134 when it is on a trusted network, so that the IPsec tunnel can be 135 dropped and the mobile node can use Mobile IP in the intranet. 137 2. Terminology 139 Many of the following terms are defined in [10], but are repeated 140 here to make this document self-contained. 142 FA: Mobile IPv4 foreign agent 144 CCoA: co-located Care-of address 146 FA-CoA: Foreign Agent Care-of address 148 FW: Firewall 150 i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet) 151 network 153 i-HA: Mobile IPv4 home agent residing in the trusted (intranet) 154 network 156 i-MIP: The mobile node uses the home agent in the internal network 158 VPN TIA: VPN tunnel inner address. This address is given out by the 159 VPN gateway during IKE negotiation and is routable in the trusted 160 network 162 mVPN: VPN with MOBIKE functionality 164 The following access modes are used in explaining the protocol. The 165 access modes are explained in more detail in [10]. 167 f: i-MIP with FA-CoA 168 c: i-MIP with CCoA 169 mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [1]. 175 3. Solution Overview 177 The mobile node is configured with a home address that remains the 178 same irrespective of whether the mobile node is inside or outside the 179 enterprise network. The mobile node is also reachable at the same 180 home address irrespective of its current point of attachment. When 181 the mobile node is connected to the intranet directly, it uses Mobile 182 IP for internal mobility. 184 When the mobile node roams and connects to an untrusted network 185 outside the enterprise, it sets up a VPN tunnel to the VPN gateway. 186 However, it still maintains a valid binding cache entry at the i-HA. 187 It uses the VPN TIA, allocated by the VPN gateway, as the co-located 188 CoA for registration with the i-HA. If the VPN TIA changes or if the 189 mobile node moves and connects to another VPN gateway, then it sends 190 a Registration Request to the i-HA using the new co-located CoA. 192 If the mobile node moves while outside the enterprise and its access 193 network changes, it uses the MOBIKE protocol to update the VPN 194 gateway of its current address. The internal home agent is not aware 195 of the mobile node's movement as long as the mobile node is attached 196 to the same VPN gateway and the TIA remains the same. 198 Figure 1 depicts the network topology assumed for the solution. It 199 also shows the possible mobile node locations and access modes. 201 (MN) {mc} {home} (MN) [i-HA] 202 ! \ / 203 .--+---. .-+---+-. 204 ( ) ( ) 205 `--+---' [MVPN] `--+----' 206 \ ! ! 207 [R/FA] .--+--. [R] 208 \ ( DMZ ) ! 209 .-+-------+--. `--+--' .-----+------. 210 ( ) ! ( ) 211 ( external net +---[R]----[FW]----[R]--+ internal net ) 212 ( ) ( ) 213 `--+---------' `---+---+----' 214 / / \ 215 [DHCP] [R] [DHCP] [R] [R] [i-FA] 216 \ / \ / \ / 217 .+--+---. .-+-+--. .--+--+-. 218 ( ) ( ) ( ) 219 `---+---' `--+---' `---+---' 220 ! ! ! 221 (MN) {mc} (MN) {c} (MN) {f} 223 Figure 1: Network Toplogy using MIPv4 and MOBIKE 225 The solution described above results in a Mobile IP tunnel inside an 226 IPsec tunnel. The Mobile IP tunnel is between the mobile node and 227 the home agent and the IPsec tunnel is between the MN and the mVPN 228 gateway. The Mobile IP tunnel uses reverse tunneling through the 229 home agent [12]. 231 3.1. Access modes 233 The following access modes are used in the solution described in this 234 document. 236 3.1.1. Access mode: 'c' 238 This access mode is standard Mobile IPv4 [2] with a co-located 239 care-of address. The mobile node must detect that it is connected to 240 an internal trusted network before using this mode. The co-located 241 care-of address is assigned by the access network to which the mobile 242 node is attached to. 244 3.1.2. Access mode: 'f' 246 This access mode is standard Mobile IPv4 [2] with a foreign agent 247 care-of address. The mobile node can use this mode only when it 248 detects that it is connected to an internal trusted network and also 249 detects a foreign agent on the access network. 251 3.1.3. Access mode: 'mc' 253 This access mode involves using both Mobile IPv4 and a MOBIKE enabled 254 IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec 255 tunnel. The mobile node uses the VPN TIA as the co-located CoA for 256 registering with the home agent. This mode is used only when the 257 mobile node is attached to an untrusted network and is required to 258 set up an IPsec tunnel with a VPN gateway to gain access to the 259 trusted network. 261 3.2. Mobility within the enterprise 263 When the mobile node is inside the enterprise network and attached to 264 the intranet, it uses Mobile IPv4 [2] for subnet mobility. The 265 mobile node uses a foreign agent care-of address, if a foreign agent 266 is available. Otherwise it acquires an address through DHCP on the 267 access link and uses it as the co-located care-of address for Mobile 268 IP. The mobile node attempts Foreign Agent discovery and CoA address 269 acquisition through DHCP simultaneously in order to avoid the delay 270 in discovering a foreign agent when there is no foreign agent 271 available. The mobile node maintains a valid binding cache entry at 272 all times at the home agent mapping the the home address to the 273 current CoA. Whenever the mobile node moves, it sends a Registration 274 Request to update the binding cache entry. 276 The Mobile IP signaling messages between the mobile node and the home 277 agent are authenticated as described in [2]. 279 The mobile node maintains a valid binding cache entry at the home 280 agent even when it is outside the enterprise network. 282 3.3. Mobility when outside the enterprise 284 When the mobile node is attached to an untrusted network, it sets up 285 an IPsec VPN tunnel with the VPN gateway to gain access to the 286 enterprise network. If the mobile node moves and its IP address 287 changes, it initiates the MOBIKE protocol [3] to update the address 288 on the VPN gateway. 290 The mobile node maintains a binding at the home agent even when it is 291 outside the enterprise network. If the TIA changes or the mobile 292 node attaches to another VPN gateway, the mobile node should send a 293 Registration Request to its home agent to update the binding cache 294 with the new TIA. 296 3.4. Crossing Security Boundaries 298 Security boundary detection is based on the reachability of the i-HA 299 from the mobile node's current point of attachment. Whenever the 300 mobile node detects that it has moved to a new IP subnet [13] and its 301 IP address changes, it sends a Registration Request to the i-HA 302 without any VPN encapsulation. If the mobile node receives a 303 Registration Reply, then it is assumes that it is on a trusted 304 network. This is based on the mechanism described in [10] to detect 305 attachment to the internal trusted network. The mobile node should 306 re-transmit the Registration Request if it does not receive the 307 Registration Reply within a timeout period. The number of times the 308 mobile node should re-transmit the Registration Request and the 309 timeout period for receiving the Registration Reply are configurable 310 on the mobile node. 312 If the mobile node has an existing VPN tunnel to its VPN gateway, it 313 MUST send a MOBIKE message at the same time as the registration 314 request to the i-HA whenever the IP address changes. If the mobile 315 node receives a response from the VPN gateway, but not from the i-HA, 316 it assumes it is outside the enterprise network. If it receives a 317 response from the i-HA, then it assumes it is inside the enterprise 318 network. 320 There could also be some out-of-band mechanisms that involve 321 configuring the wireless access points with some information which 322 the mobile node can recognize as access points that belong to the 323 trusted network in an enterprise network. Such mechanisms are beyond 324 the scope of this document. 326 3.4.1. Operation when moving from an untrusted network 328 When the mobile node is outside the enterprise network and attached 329 to an untrusted network, it has an IPsec VPN tunnel with its mobility 330 aware VPN gateway, and a valid registration with a home agent on the 331 intranet with the VPN TIA as the care-of address. 333 If the mobile nodes moves and its IP address changes, it performs the 334 following steps: 336 1a. Initiate an IKE mobility exchange to update the VPN gateway with 337 the current address. If the new network is also untrusted, this 338 will be enough for setting up the connectivity. If the new 339 network is trusted, and if the VPN gateway is reachable, this 340 exchange will allow the mobile node to keep the VPN state alive 341 while on the trusted side. If the VPN gateway is not reachable 342 from inside, then this exchange will fail. 344 1b. At the same time as step 1, send a Mobile IPv4 Registration 345 Request to the internal home agent without VPN encapsulation. 346 2. If the mobile node receives a Registration Reply to the request 347 sent in step 2, then the current subnet is a trusted subnet, and 348 the mobile node can communicate without VPN tunneling. The mobile 349 node MAY tear down the VPN tunnel. 351 3.4.2. Operation when moving from a trusted network 353 When the mobile node is inside the enterprise and attached to the 354 intranet, it does not use a VPN tunnel for data traffic. It has a 355 valid binding cache entry at its home agent. If the VPN gateway is 356 reachable from the trusted network, the mobile node MAY have valid 357 IKEv2 security associations with its VPN gateway. The IPsec security 358 associations can be created when required. The mobile node may have 359 to re-negotiate the IKEv2 security associations to prevent them from 360 expiring. 362 If the mobile node moves and its IP address changes, it performs the 363 following steps: 365 1. Initiate an IKE mobility exchange to update the VPN gateway with 366 the current address, or if there is no VPN connection, then 367 establish a VPN tunnel with the gateway from the new local IP 368 address. If the new network is trusted, and if the VPN gateway 369 is reachable, this exchange will allow the mobile node to keep 370 the VPN state alive, while in the trusted side. If the new 371 network is trusted and if the VPN gateway is not reachable from 372 inside, then this exchange will fail. 373 2. At the same time as step 1, send a Mobile IPv4 Registration 374 Request to the internal home agent without VPN encapsulation. 375 3. If the mobile node receives a Registration Reply to the request 376 sent in step 2, then the current subnet is a trusted subnet, and 377 the mobile node can communicate without VPN tunneling, using only 378 Mobile IP with the new care-of address. 379 4. If the mobile node didn't receive the response in step 3, and if 380 the VPN tunnel is successfully established and registered in step 381 1, then the mobile node sends a Registration Request over the VPN 382 tunnel to the internal home agent. After receiving a 383 Registration Reply from the home agent, the mobile node can start 384 communicating over the VPN tunnel with the Mobile IP home 385 address. 387 4. NAT Traversal 389 There could be a NAT device between the mobile node and the home 390 agent in any of the access modes, 'c', 'f' and 'mc', and between the 391 mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 392 NAT traversal, as described in [7] should be used by the mobile node 393 and the home agent in access modes 'c' or 'f', when there is a NAT 394 device present. When using access mode, 'mc', IPsec NAT traversal 395 [8] [9] should be used by the mobile node and the VPN gateway, if 396 there is a NAT device present. Typically, the TIA would be a 397 routable address inside the enterprise network. But in some cases, 398 the TIA could be from a private address space associated with the VPN 399 gateway. In such a case, Mobile IPv4 NAT traversal should be used in 400 addition to IPsec NAT traversal in the 'mc' mode. 402 5. Security Considerations 404 Enterprise connectivity typically requires very strong security, and 405 the solution described in this document was designed keeping this in 406 mind. 408 Security concerns related to the mobile node detecting that it is on 409 a trusted network and thereafter dropping the VPN tunnel are 410 described in [10]. 412 Please see [3] for MOBIKE-related security considerations, and [7], 413 [8] for security concerns related to the use of NAT traversal 414 mechanisms for Mobile IPv4 and IPsec. 416 6. IANA Considerations 418 This document requires no action from IANA. 420 7. Acknowledgments 422 The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval 423 Shah and John Cruz for their participation in developing this 424 solution. 426 The authors would also like to thank Henrik Levkowetz, Jari Arkko and 427 TJ Kniveton for reviewing the document. 429 8. References 431 8.1. Normative References 433 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 434 Levels", BCP 14, RFC 2119, March 1997. 436 [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 437 August 2002. 439 [3] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 440 draft-ietf-mobike-protocol-07 (work in progress), 441 December 2005. 443 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 444 RFC 4306, December 2005. 446 [5] Kent, S. and K. Seo, "Security Architecture for the Internet 447 Protocol", RFC 4301, December 2005. 449 [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 450 RFC 2409, November 1998. 452 [7] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network 453 Address Translation (NAT) Devices", RFC 3519, May 2003. 455 [8] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 456 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 457 January 2005. 459 [9] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 460 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, 461 January 2005. 463 [10] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across 464 IPsec-based VPN Gateways", 465 draft-ietf-mip4-vpn-problem-solution-02 (work in progress), 466 November 2005. 468 8.2. Informative References 470 [11] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 471 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, 472 August 2005. 474 [12] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", 475 RFC 3024, January 2001. 477 [13] Aboba, B., "Detecting Network Attachment in IPv4 (DNAv4)", 478 draft-ietf-dhc-dna-ipv4-18 (work in progress), December 2005. 480 Authors' Addresses 482 Vijay Devarapalli 483 Nokia Research Center 484 313 Fairchild Drive 485 Mountain View, CA 94043 486 USA 488 Email: vijay.devarapalli@nokia.com 490 Pasi Eronen 491 Nokia Research Center 492 P.O. Box 407 493 FIN-00045 Nokia Group 494 Finland 496 Email: pasi.eronen@nokia.com 498 Intellectual Property Statement 500 The IETF takes no position regarding the validity or scope of any 501 Intellectual Property Rights or other rights that might be claimed to 502 pertain to the implementation or use of the technology described in 503 this document or the extent to which any license under such rights 504 might or might not be available; nor does it represent that it has 505 made any independent effort to identify any such rights. Information 506 on the procedures with respect to rights in RFC documents can be 507 found in BCP 78 and BCP 79. 509 Copies of IPR disclosures made to the IETF Secretariat and any 510 assurances of licenses to be made available, or the result of an 511 attempt made to obtain a general license or permission for the use of 512 such proprietary rights by implementers or users of this 513 specification can be obtained from the IETF on-line IPR repository at 514 http://www.ietf.org/ipr. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary 518 rights that may cover technology that may be required to implement 519 this standard. Please address the information to the IETF at 520 ietf-ipr@ietf.org. 522 Disclaimer of Validity 524 This document and the information contained herein are provided on an 525 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 526 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 527 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 528 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 529 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 530 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 532 Copyright Statement 534 Copyright (C) The Internet Society (2006). This document is subject 535 to the rights, licenses and restrictions contained in BCP 78, and 536 except as set forth therein, the authors retain all their rights. 538 Acknowledgment 540 Funding for the RFC Editor function is currently provided by the 541 Internet Society.