idnits 2.17.1 draft-xia-mip6-fw-policy-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, updated by RFC 4748 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 527. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 2007) is 6190 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) == Unused Reference: 'RFC3776' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC4067' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC4487' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC3304' is defined on line 463, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Downref: Normative reference to an Historic RFC: RFC 3084 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-rfc4285bis-00 == Outdated reference: A later version (-08) exists of draft-thiruvengadam-nsis-mip6-fw-06 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Expires: November 2, 2007 Huawei USA 5 May 2007 7 Policy-based Firewall Traversal for Mobile IPv6 8 draft-xia-mip6-fw-policy-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 November 2, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Most of firewalls deployed today are Mobile IPv6 unaware. Widespread 42 Mobile IPv6 deployment is not possible unless Mobile IPv6 messages 43 can pass through these firewalls. In this memo, policy servers are 44 used to communicate with firewalls and instruct them to bypass Mobile 45 IPv6 messages. To achieve the goal, Network Access Identifier (NAI) 46 and authentication information are included in Mobile IPv6 control 47 signalling or data packets. Firewalls extract these information and 48 send them to a policy server, and the policy server then installs 49 corresponding states in firewalls based on authentication result and 50 user's predefined policy. The new defined IPv6 extension header and 51 the policy-based frame can also facilitate dynamic configuration in 52 any application firewall traversal. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Policy Control Framework . . . . . . . . . . . . . . . . . . . 3 59 4. Middlebox Communication architecture . . . . . . . . . . . . . 4 60 5. Mobile node behind a firewall . . . . . . . . . . . . . . . . 4 61 5.1. Binding Updates and Binding Acknowledgement . . . . . . . 5 62 5.2. Route optimization . . . . . . . . . . . . . . . . . . . . 6 63 5.3. Change of Firewalls . . . . . . . . . . . . . . . . . . . 6 64 6. Correspondent Node behind a firewall . . . . . . . . . . . . . 6 65 6.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 7 66 7. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 7 67 8. New IPv6 Extension Header . . . . . . . . . . . . . . . . . . 8 68 8.1. Middlebox Hop Header Description . . . . . . . . . . . . . 8 69 8.2. Extension Header Order . . . . . . . . . . . . . . . . . . 9 70 8.3. Process . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9. Consideration of Mobile IPv6 Authentication Protocol . . . . . 10 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 11. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 13.2. Informative references . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Intellectual Property and Copyright Statements . . . . . . . . . . 14 81 1. Introduction 83 In [RFC3775], route optimization, bi-directional tunneling, and ESP 84 encapsulated binding update are integral parts of Mobile IPv6 85 specification. Most corporate firewalls (among others) are typically 86 configured to disallow IP in IP tunneling and ESP, by default. Such 87 configuration would prevent MIPv6 control messages and normal data to 88 pass through those firewalls. 90 [I-D.thiruvengadam-nsis-mip6-fw] applies NSIS signaling for these 91 problems, and the main disadvantage of the proposal is that 92 complicated signaling should be implemented within mobile nodes and 93 correspondent nodes. 95 A framework for policy-based admission control is described in 96 [RFC2753]. The framework can also be used for Mobile IPv6 firewall 97 traversal. A firewall intercepts Mobile IPv6 message and requests a 98 server for policies. The server then instructs firewalls to build 99 related states for future traffic. 101 Generally, Mobile IPv6 has mechanisms that control signalling is 102 separated from data traffic. Piggybacking control messages ( such as 103 Binding Update,Binding Acknowledgement), authentication information 104 can be used to build states in firewalls. A New IPv6 Extension 105 Header called Middlebox Hop is defined to hold these authentication 106 information. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 Policy: The combination of rules and services where rules define the 115 criteria for resource access and usage 116 PDP: The point where policy decisions are made 117 PEP: The point where the policy decisions are actually enforced 119 3. Policy Control Framework 121 The framework is described in [RFC2753]. The two main architectural 122 elements of the framework for policy control are the PEP and the PDP. 123 Figure 1 shows a simple configuration involving these two elements; 124 PEP is a component at a network node and PDP is a remote entity that 125 may reside at a policy server. The PEP represents the component that 126 always runs on the policy aware node. It is the point at which 127 policy decisions are actually enforced. Policy decisions are made 128 primarily at the PDP. The PDP itself may make use of additional 129 mechanisms and protocols to achieve additional functionality such as 130 user authentication, accounting, policy information storage, etc. 132 The basic interaction between the components begins with the PEP. 133 The PEP receives a notification or a message that requires a policy 134 decision. Given such an event, the PEP then formulates a request and 135 sends it to the PDP. The PDP returns the policy decision and the PEP 136 then enforces the policy decision by appropriately accepting or 137 denying the request. 139 ________________ _________________ 140 | | | | LDAP,SNMP,AAA,.. 141 | Network Node | | Policy server | for accessing 142 | _____ | | _____ | policy database, 143 | | | | | | | | authentication,etc. 144 | | PEP |<-----|--------|-->| PDP |------|----------------> 145 | |_____| | | |_____| | 146 | | | | 147 |________________| |________________| 149 Figure 1: architectural elements 151 4. Middlebox Communication architecture 153 [RFC3303] describes a framework of middlebox communications (MIDCOM) 154 to enable complex applications through the middleboxes, seamlessly 155 using a trusted third party. Middleboxes implementing Firewall 156 service typically embed application intelligence within the device. 157 In [RFC3303], firewalls offload application intelligence to trusted 158 third parties, as allows firewalls to continue to provide the 159 services, while keeping the firewalls application agnostic. In this 160 proposal,we combine Policy Control Framework and Middlebox 161 Communication architecture. Firewalls offload MIPv6 intelligence to 162 Policy server, and Policy server download rules for firewalls' 163 operation. 165 5. Mobile node behind a firewall 167 In Figure 2, An MN is protected by a firewall that employs stateful 168 packet filtering. An external CN and an HA are also shown in the 169 figure. The MN is located in a visited network and is expecting to 170 communicate with the CN. 172 +----------------+ +----+ 173 | | | HA | 174 | | +----+ 175 | | Home Agent 176 | +----+ +----+ 177 | | MN | | FW | 178 | +----+ +----+ 179 | | +----+ 180 | | | CN | 181 | | +----+ 182 +----------------+ External CN 183 Network protected 184 by a firewall 186 Figure 2: MN behind a firewall 188 5.1. Binding Updates and Binding Acknowledgement 190 In [RFC3775], IPsec is used to protect Binding Updates (BU) and 191 Binding Acknowledgement(BAck).Most corporate firewalls (among others) 192 are typically configured to disallow IP in IP tunneling and ESP, by 193 default. Such configuration would prevent MIPv6 control messages and 194 normal data to pass through those firewalls. As a solution, a policy 195 server can be used to dynamically configure the firewall(s) based on 196 authentication . Network Access Identifier (NAI) [RFC4282] and 197 Mobility Message Authentication Option defined in [RFC4285] should be 198 included in BU/BAck. A new IPv6 extension header called Middlebox 199 Hop is designed in Section 8 to hold these information. The process 200 is as following: 201 o The firewall(PEP) extracts NAI and authentication information from 202 Middlebox Hop Header in BU/BAck, and sends them to a policy server 203 (PDP) through COPS-PR [RFC3084], RADIUS/Diameter, or other 204 protocols. To facilitate policy server to configure firewalls 205 dynamically and intellectually, support information can be sent to 206 policy servers. One simple practice is sending TCP/IP, UDP/IP 207 header to policy servers, or foward the complete packet to the 208 server through a tunnel between the Policy server and the 209 firewall. 210 o The policy server makes use of additional mechanisms and 211 protocols, such as LDAP, SNMP and so on, to retrieve the user's 212 profile from policy depository or user database. Details of these 213 mechanisms are out of the scope. 215 o If the user passes the authentication, the policy server build 216 policy and rules for the user and sends these information to the 217 firewall for creating states. 219 The states installed by the policy server allow the following 220 traffic: 221 o HOTI and HOT for route optimization. 222 o Bi-directional tunneling traffic. 224 5.2. Route optimization 226 Route optimization includes two parts, Return Routability Test (RRT) 227 and Binding Updates (BU). MN initiates RRT procedure with HoTI 228 message. HOTI and HOT can traverse the firewall because there are 229 related states installed as described in Section 5.1. In general 230 speaking, firewalls don't filter outgoing traffic, and make use of 231 outgoing traffic to build related states for incoming traffic. The 232 CoTI/ CoT message and the BU/BAck message can traverse the MN's ASP- 233 firewall, as the CoTI/BU message are not IPsec encapsulated and the 234 CoT/BAck messages correspond to the state previously installed by the 235 CoTI message. 237 5.3. Change of Firewalls 239 If the MN roams and attaches to a different firewall, the above- 240 mentioned routing methods will have problems in traversing the new 241 firewall. The same procedure can just repeat. There are also access 242 routers with built-in firewalls. In this case, context transfer can 243 be used to synchronize states between firewalls together with 244 handover. 246 6. Correspondent Node behind a firewall 248 In Figure 3, the CN is protected by a firewall that employs stateful 249 packet filtering. An external MN and its associated HA are also 250 shown in the figure. The MN communicates with the CN. If the CN 251 initiated normal data traffic there is no problem with the SPF, as 252 the communication is initiated from internal. If MN reaches CN 253 through bi-directional tunnel between MN and HA, a Middlebox Hop 254 defined in Section 8 is included in first data packet to create a 255 pinhole in the firewall. 257 +----------------+ +----+ 258 | | | HA | 259 | | +----+ 260 | | Home Agent 261 | +----+ +----+ 262 | | CN | | FW | 263 | +----+ +----+ 264 | | +----+ 265 | | | MN | 266 | | +----+ 267 +----------------+ External Mobile 268 Network protected Node 269 by a firewall 271 Figure 3: CN behind the firewall 273 6.1. Route Optimization 275 The MN moves out of its home network and has to perform the return 276 routability test before sending the binding update to the CN. It 277 sends a HoTI message through the HA to the CN and expects a HoT 278 message from the CN along the same path. It also sends a CoTI 279 message directly to the CN and expects CoT message in the same path 280 from the CN. To allow HoTI and CoTI, A Middlebox Hop Header with NAI 281 and authentication information is included in these messages, and 282 there are related states installed after process as described above 283 sections. 285 7. Home Agent behind a firewall 287 In Figure 4, A Home Agent is protected by a firewall. An MN and a CN 288 are also shown in the figure. The MN, after entering a new network, 289 sends a Binding Update to the HA. To allow BU, A Middlebox Hop 290 Header with NAI and authentication information is included in the 291 message. A policy server installs states to the firewall after 292 successful authentication of the user. 294 +----------------+ +----+ 295 | | | MN | 296 | | +----+ 297 | | Mobile Node 298 | +----+ +----+ 299 | | HA | | FW | 300 | +----+ +----+ 301 | | +----+ 302 | | | CN | 303 | | +----+ 304 +----------------+ External CN 305 Network protected 306 by a firewall 308 Figure 4: Home Agent behind a firewall 310 8. New IPv6 Extension Header 312 8.1. Middlebox Hop Header Description 314 Some IPv6 Extension Headers are defined in [RFC2460]. A new IPv6 315 Extension Header called Middlebox Hop is defined here. 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Next Header | Hdr Ext Len | MIDBOX Type | Reserved | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 . . 322 . Options . 323 . . 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Next Header 8-bit selector. Identifies the type of header 328 immediately following the Middlebox Hop Options 329 header. 331 Hdr Ext Len 8-bit unsigned integer. Length of the Middlebox 332 Options header in 8-octet units, not including 333 the first 8 octets. 335 MIDBOX Type 8-bit unsigned integer. Types of Middleboxes 336 are defined in [RFC3234]. In this document, 337 only firewall is referred to. 339 Options Variable-length field, of length such that the 340 complete Middlebox Hop Options header is an integer 341 multiple of 8 octets long. In MIPv6 firewall 342 traversal scenario, MN-NAI Mobility Option defined 343 in [RFC4283] and Mobility Message Authentication 344 Option defined in [RFC4285] are necessary. 346 8.2. Extension Header Order 348 When more than one extension header is used in the same packet, those 349 headers appear in the order defined in [RFC2460], and other 350 documents, such as [RFC3775] and so forth. The Middlebox Hop 351 extension header should occur at most once. The header is 352 immediately after Hop-by-Hop Option header. 354 IPv6 header 355 Hop-by-Hop Options header 356 Middlebox Hop 357 Destination Options header (note 1) 358 Routing header 359 Fragment header 360 Authentication header 361 Encapsulating Security Payload header 362 Destination Options header 363 upper-layer header 365 note 1: for options to be processed by the first destination 366 that appears in the IPv6 Destination Address field 367 plus subsequent destinations listed in the Routing 368 header. 370 8.3. Process 372 The IPv6 extension header is only used for the process of middlebox 373 defined in [RFC3234]. Any other network nodes just ignore the 374 header. In MIPv6 firewall traversal scenario, BU and Back includes 375 the header to create a pinhole in firewalls en route between MN and 376 HA. The header is also included in control signalling or first data 377 packet exchange between MN and CN, or between HA and CN to traverse 378 firewalls. Firewalls intercept packets with the IPv6 extension 379 header, extract authentication material in the options and send them 380 to policy servers together with other support information, such as 381 source IP address, destination IP address, protocol type and so on. 382 Policy server download rules for firewalls. 384 9. Consideration of Mobile IPv6 Authentication Protocol 386 As an alternative of [RFC3775], [I-D.ietf-mip6-rfc4285bis] proposes a 387 method for securing MIPv6 signaling messages between Mobile Nodes and 388 Home Agents. The alternate method consists of a MIPv6-specific 389 mobility message authentication option that can be added to MIPv6 390 signaling messages. In such case, Middlebox Hop extension header may 391 not be included in related messages. 393 10. Security Considerations 395 This proposal is based on the frame work defined in [RFC2753], and no 396 additional security problem is introduced. 398 11. IANA consideration 400 None. 402 12. Acknowledgements 404 13. References 406 13.1. Normative References 408 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 409 in IPv6", RFC 3775, June 2004. 411 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 412 Protect Mobile IPv6 Signaling Between Mobile Nodes and 413 Home Agents", RFC 3776, June 2004. 415 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 416 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 417 (MIPv6)", RFC 4283, November 2005. 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 423 Network Access Identifier", RFC 4282, December 2005. 425 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 426 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 427 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 428 RFC 3084, March 2001. 430 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 431 (IPv6) Specification", RFC 2460, December 1998. 433 13.2. Informative references 435 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 436 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 438 [I-D.ietf-mip6-rfc4285bis] 439 Patel, A., "Authentication Protocol for Mobile IPv6", 440 draft-ietf-mip6-rfc4285bis-00 (work in progress), 441 March 2007. 443 [I-D.thiruvengadam-nsis-mip6-fw] 444 Tschofenig, H., "Mobile IPv6 - NSIS Interaction for 445 Firewall traversal", draft-thiruvengadam-nsis-mip6-fw-06 446 (work in progress), March 2007. 448 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 449 for Policy-based Admission Control", RFC 2753, 450 January 2000. 452 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 453 IPv6 and Firewalls: Problem Statement", RFC 4487, 454 May 2006. 456 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 457 Issues", RFC 3234, February 2002. 459 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 460 A. Rayhan, "Middlebox communication architecture and 461 framework", RFC 3303, August 2002. 463 [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, 464 "Middlebox Communications (midcom) Protocol Requirements", 465 RFC 3304, August 2002. 467 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 468 Chowdhury, "Authentication Protocol for Mobile IPv6", 469 RFC 4285, January 2006. 471 Authors' Addresses 473 Frank Xia 474 Huawei USA 475 1700 Alma Dr. Suite 100 476 Plano, TX 75075 478 Phone: +1 972-509-5599 479 Email: xiayangsong@huawei.com 481 Behcet Sarikaya 482 Huawei USA 483 1700 Alma Dr. Suite 100 484 Plano, TX 75075 486 Phone: +1 972-509-5599 487 Email: sarikaya@ieee.org 489 Full Copyright Statement 491 Copyright (C) The IETF Trust (2007). 493 This document is subject to the rights, licenses and restrictions 494 contained in BCP 78, and except as set forth therein, the authors 495 retain all their rights. 497 This document and the information contained herein are provided on an 498 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 499 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 500 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 501 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 502 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 503 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 505 Intellectual Property 507 The IETF takes no position regarding the validity or scope of any 508 Intellectual Property Rights or other rights that might be claimed to 509 pertain to the implementation or use of the technology described in 510 this document or the extent to which any license under such rights 511 might or might not be available; nor does it represent that it has 512 made any independent effort to identify any such rights. Information 513 on the procedures with respect to rights in RFC documents can be 514 found in BCP 78 and BCP 79. 516 Copies of IPR disclosures made to the IETF Secretariat and any 517 assurances of licenses to be made available, or the result of an 518 attempt made to obtain a general license or permission for the use of 519 such proprietary rights by implementers or users of this 520 specification can be obtained from the IETF on-line IPR repository at 521 http://www.ietf.org/ipr. 523 The IETF invites any interested party to bring to its attention any 524 copyrights, patents or patent applications, or other proprietary 525 rights that may cover technology that may be required to implement 526 this standard. Please address the information to the IETF at 527 ietf-ipr@ietf.org. 529 Acknowledgment 531 Funding for the RFC Editor function is provided by the IETF 532 Administrative Support Activity (IASA).