idnits 2.17.00 (12 Aug 2021) /tmp/idnits49531/draft-eggert-middlebox-control-survey-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. 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 document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (June 23, 2007) is 5445 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-cheshire-nat-pmp has been published as RFC 6886 == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: A later version (-05) exists of draft-wing-behave-nat-control-stun-usage-02 == Outdated reference: A later version (-03) exists of draft-woodyatt-ald-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Eggert 3 Internet-Draft P. Sarolahti 4 Intended status: Informational R. Denis-Courmont 5 Expires: December 25, 2007 V. Stirbu 6 Nokia 7 June 23, 2007 9 A Survey of Protocols to Control Network Address Translators and 10 Firewalls 11 draft-eggert-middlebox-control-survey-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 This document may not be modified, and derivative works of it may not 20 be created, except to publish it as an RFC and to translate it into 21 languages other than English. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 25, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document surveys existing protocols for the control of network 48 address translators and firewalls. It includes standards-level 49 protocols developed by the IETF and other standards organizations as 50 well as protocols designed by individuals. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Standards-Track Protocols from the IETF . . . . . . . . . . . 4 56 2.1. SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. NSIS - NAT/Firewall Signaling Layer Protocol . . . . . . . 5 58 2.3. MIDCOM - Managed Objects for Middlebox Communication . . . 5 59 2.4. SIMCO - NEC's Simple Middlebox Configuration Protocol . . 5 60 3. Standards-Level Protocols from other Organizations . . . . . . 5 61 3.1. UPnP - Internet Gateway Device Standardized Device 62 Control Protocol . . . . . . . . . . . . . . . . . . . . . 6 63 4. Other Protocols . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. NAT-PMP - NAT Port Mapping Protocol . . . . . . . . . . . 7 65 4.2. STUN - Controlling NAT Bindings using STUN . . . . . . . . 8 66 4.3. RSIP - Realm-Specific IP . . . . . . . . . . . . . . . . . 8 67 4.4. ALD - Application Listener Discovery for IPv6 . . . . . . 8 68 4.5. NLS - Network Layer Signaling Transport Layer . . . . . . 9 69 4.6. AFWC - Authorized IP Firewall Control Application . . . . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Informative References . . . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Intellectual Property and Copyright Statements . . . . . . . . . . 13 77 1. Introduction 79 Network address translators (NATs) and firewalls - frequently 80 referred to as "middleboxes" - are a subject of active discussion in 81 the IETF and related development and standardization communities. 82 These devices are not part of the traditional end-to-end Internet 83 architecture, because they usually operate on transport- and higher- 84 layer information inside the network, which is a layering violation 85 in the original architecture, because operating on that information 86 was the exclusive providence of the end-hosts. 88 However, in practice, NATs have turned out to be necessary to be able 89 to mitigate the IPv4 address space limitations of many network 90 domains. Similarly, because the networking software in many systems 91 has turned out to contain security defects of different kinds, use of 92 firewalls is common to protect the systems from attacks coming from 93 the network. Another motivation for firewalls is to protect against 94 the abuse of possibly scarce of expensive bandwidth, for example, 95 unwanted traffic on wireless links. 97 A shared disadvantage of NATs and firewalls is that they often encode 98 knowledge about a particular set of higher-layer protocols and 99 applications in order to operate. This practice prevents new types 100 of network protocols or applications from being deployed end-to-end, 101 unless the middleboxes are upgraded or reconfigured as well. For 102 example, a firewall is usually configured with a list of ports for a 103 set of common network applications, preventing introduction of new 104 applications. Furthermore, they commonly only support traditional 105 transport protocols, such as TCP and UDP, preventing the use of other 106 protocols, such as IPsec, IP tunneling, or other transport protocols. 107 In addition, many NATs and firewalls maintain some state for each 108 active transport-layer session that typically needs to be refreshed 109 in constant intervals, and can be initiated only by certain hosts. 111 To overcome the above-mentioned limitations, the different protocols 112 and applications have needed to adapt to the behavior of NATs and 113 firewalls. Commonly, new protocols must be encapsulated into UDP 114 packets in order to pass through these devices. Although the UDP 115 header and protocol logic are minimal and do not consume much network 116 capacity, the use of UDP causes other problems, because it is not 117 connection-oriented. Because there are no messages for connection 118 establishment or connection tear-down in UDP, a stateful NAT or 119 firewall needs to monitor ongoing UDP traffic between a source and 120 destination, and in the absence of such traffic assumes that the 121 session has ended, removing the related session state. In practice, 122 the timers for state clean-up have turned out to be short (on the 123 order of seconds), requiring the end hosts to transmit frequent and 124 resource-consuming keep-alive messages to refresh the session state 125 maintained at middleboxes. 127 A more advanced method to overcome the limitations caused by NATs or 128 firewalls would be to allow end-hosts to signal their communication 129 characteristics and profiles explicitly to the NATs and firewalls, or 130 alternatively to allow these devices to signal their configuration 131 information to the end-hosts. With such schemes, the number of 132 state-refreshing keep-alives could be significantly reduced, and NATs 133 and firewalls could be made directly aware of the communication 134 characteristics of the end-hosts. 136 A number of existing protocols have been proposed for this purpose, 137 and new proposals are being prepared. This document aims to support 138 such efforts by surveying existing proposals and by discussing the 139 the benefits and shortcomings of these schemes. 141 2. Standards-Track Protocols from the IETF 143 2.1. SOCKS 145 2.1.1. Protocol Overview 147 The SOCKS Protocol Version 5 [RFC1928] defines a method for nodes 148 located on an IP network (such as an Intranet with no routing to the 149 Internet) to establish TCP sessions and exchange UDP datagrams with 150 another IP network (usually the global Internet). To that end, a 151 SOCKS server must be located on the boundary of both networks, and 152 SOCKS clients must explicitly request the server to relay their 153 communication sessions. 155 When a SOCKS client establishes a TCP session to the remote network, 156 it first connects to the SOCKS server on a well-known TCP port, 157 sending a connection request with optional authentication 158 credentials. The request specifies in which direction the TCP 159 session is to be established, i.e., whether the SOCKS server will act 160 as the active or passive endpoint. The SOCKS server, if it accepts 161 the request, informs the client of the external IP address and TCP 162 port number that it will use. If the SOCKS server acts as the 163 passive endpoint, it sends an additional response once the TCP three- 164 way handshake is completed. The SOCKS server then forwards traffic 165 between the internal and external TCP sessions, until either of them 166 is terminated. 168 UDP sessions are also initially negotiated via a TCP session to the 169 SOCKS server, in a similar manner. If successful, the client obtains 170 the IP address and UDP port number of a UDP relay server. The relay 171 forwards UDP datagrams between the local and remote networks. When 172 sending a datagram, the client adds an additional, SOCKS-specific 173 header, which carries the IP address or DNS name of the remote peer 174 and the intended destination UDP port number of the datagram. The 175 relay adds the same header when forwarding datagrams from the remote 176 network back to the client. 178 2.1.2. Protocol Analysis 180 The SOCKS protocol makes few assumptions about the network 181 environment it operates in. In particular, there can be any number 182 NAT/firewall devices between the client and the SOCKS server, and 183 there need not be a router between the local and remote networks. It 184 is assumed that the SOCKS server itself can freely exchange TCP and 185 UDP packets with the remote network. 187 SOCKS supports both IPv4 and IPv6 as well as translation from one to 188 the other. SOCKS only supports UDP and TCP as transport protocols. 189 Conveyance of IP header parameters other than the IP addresses (such 190 as IP options, hop limit, TOS field, etc.) are not defined. SOCKS 191 cannot be used for generic server applications: only one passive TCP 192 session per request is allowed. 194 The protocol is mature and implementations for clients and servers 195 are widely available. SOCKS is supported in many FTP and HTTP 196 clients. Applications must usually be modified to support SOCKS, but 197 it is also possible to implement SOCKS transparently as a shim layer 198 above the BSD socket API. 200 SOCKS requires manual configuration on the client. SOCKS server 201 address and optional credentials must be explicitly provisioned. 203 2.2. NSIS - NAT/Firewall Signaling Layer Protocol 205 To be completed [I-D.ietf-nsis-nslp-natfw]. 207 2.3. MIDCOM - Managed Objects for Middlebox Communication 209 To be completed [RFC3303]. 211 2.4. SIMCO - NEC's Simple Middlebox Configuration Protocol 213 To be completed [RFC4540]. 215 3. Standards-Level Protocols from other Organizations 216 3.1. UPnP - Internet Gateway Device Standardized Device Control 217 Protocol 219 3.1.1. Protocol Overview 221 The Internet Gateway Device (IGD) is an "edge" interconnection device 222 between a residential Local Area Network (LAN) and a Wide Area 223 Network (WAN), providing connectivity to the Internet for the 224 networked devices in the residential network. The IGD could be 225 physically implemented as a dedicated, standalone device or modeled 226 as a set of Universal Plug-and-Play (UPnP) devices and services on a 227 personal computer. 229 As an UPnP-based protocol, the IGD Standardized Device Control 230 Protocol [UPNP] inherits the features that the UPnP Device 231 Architecture provides for support zero-configuration, "invisible" 232 networking, and automatic discovery for a breadth of device 233 categories. Any device can dynamically join a network, obtain an IP 234 address, announce its name, convey its capabilities upon request, and 235 learn about the presence and capabilities of other devices. Devices 236 can disconnect from the network automatically without leaving any 237 unwanted state information behind. 239 The IGD Standardized Device Control Protocol contains a set of 240 devices and services that allow clients (in the UPnP context also 241 called "Control Points") to control the initiation and termination of 242 connections, monitor status and events of connections, or manage host 243 configuration services, e.g., DHCP or Dynamic DNS. Among these 244 services, the "WANIPConnection" service provides the functionality 245 that allows the Control Points to manage the network address 246 translation on the IGD device. 248 The IGD Standardized Device Control Protocol preserves the ability of 249 non-UPnP devices to initiate and/or share Internet access. 251 3.1.2. Protocol Analysis 253 The IGD Standardized Device Control Protocol is intended to be used 254 in unmanaged network environments such as those found typically in 255 residential networks. The residential network can have up to four 256 segments, a limitation inherited from the UPnP Device Architecture, 257 because the TTL value for the link-local multicast discovery messages 258 is four. 260 By design, the protocol does permit the presence of several 261 residential gateways in the same network and also permits residential 262 gateways to have multiple connections to the Internet. In practice, 263 a lack of routing mechanisms across multiple, simultaneously active 264 WAN connections on multiple WAN interfaces and related issues caused 265 by multiple, simultaneously active Internet Gateway devices (e.g., 266 default gateway conflict resolution, load balancing or fail over) 267 make scenarios other than that of a single Gateway Device with a 268 single Internet connection difficult to support. 270 A residential gateway supporting the IGD Standardized Device Control 271 Protocol is able to operate in two modes. In "routed mode", the 272 gateway shares the routable WAN IP address with the control points on 273 the LAN using NAT. In "bridged" mode, all Ethernet packets from 274 devices on the LAN are bridged to the WAN. In scenarios where the IP 275 address on the WAN interface is not routable, the device can be 276 switched from routed to bridged mode, allowing both the discovery of 277 IGD Standardized Device Control Protocol devices further along the 278 path as well as the use of other NAT hole-punching protocols. 280 Applications that intend to create port mappings on a residential 281 gateway supporting the IGD Standardized Device Control Protocol need 282 to have embedded control point functionality, enabling them to create 283 port mappings from TCP or UDP port on the external IPv4 address to 284 the corresponding ports on the internal IPv4 addresses. 286 The protocol is implemented in more than 90% of the consumer routers, 287 although the functionality might not be enabled by default. 289 4. Other Protocols 291 4.1. NAT-PMP - NAT Port Mapping Protocol 293 4.1.1. Protocol Overview 295 The NAT Port Mapping Protocol [I-D.cheshire-nat-pmp] is a light- 296 weight binary protocol running on top of UDP between client hosts and 297 their IPv4 gateway. Clients can send requests to their first-hop 298 gateway on a well-known UDP port, in order to determine whether NAT- 299 PMP is supported. If that is the case, they will also learn the 300 external IPv4 address of the gateway device. 302 If the gateway supports NAT-PMP, a host can assume that it is behind 303 a NAT and start sending request for mapping of external TCP or UDP 304 ports on the external IPv4 address. Mappings can be destroyed 305 explicitly. They also automatically expire after a timeout that can 306 be negotiated per mapping, unless refreshed. 308 Through the use of link-local multicast, the gateway can notify hosts 309 if its external IP changes, and/or if it has rebooted. In the latter 310 case, hosts are expected to recreate any mappings. This procedure 311 attempts to protect against loss of state at the gateway. 313 NAT-PMP assumes that there is one and only one NAT along the path, 314 which also has to be the first-hop gateway. A gateway must not 315 enable NAT-PMP if it is does not perform address/port translation. 317 4.1.2. Protocol Analysis 319 NAT-PMP is applicable to small, unmanaged, non-routed networks, 320 connecting multiple hosts to the IPv4 Internet through a single 321 public IPv4 address. It does not require any configuration. Support 322 from the gateway can be auto-detected by clients, and the trust model 323 is solely based on network attachment. There is no support for IPv6, 324 nor is there support for transport protocols other than TCP or UDP. 325 Nested NATs and non-NAT'ing firewalls are not supported. 327 NAT-PMP covers the same use cases as [UPNP], although it is not as 328 widely deployed today. (NAT-PMP is currently mostly implemented by 329 equipment from Apple Computer, Inc.). The specification is recent, 330 but nevertheless mature. 332 Applications will normally need to be modified to explicitly request 333 port mappings from the operating system, which would then operate the 334 NAT-PMP state machine and message handling. By design, the protocol 335 allows applications to expose services to the outside, so hole- 336 punching could conceivably be done automatically whenever an 337 application listens to a local TCP port (although this would probably 338 have unwelcome security implications). 340 4.2. STUN - Controlling NAT Bindings using STUN 342 To be completed [I-D.wing-behave-nat-control-stun-usage]. 344 4.3. RSIP - Realm-Specific IP 346 To be completed [RFC3103]. 348 4.4. ALD - Application Listener Discovery for IPv6 350 4.4.1. Protocol Overview 352 Application Listener Discovery for IPv6 [I-D.woodyatt-ald] is a 353 light-weight, binary protocol to explicitly punch holes through 354 stateful IPv6 firewalls. It uses ICMPv6 for signaling and is auto- 355 configured through an explicit ICMPv6 router advertisement option. 357 If the gateway supports ALD, a host can request the opening of holes 358 for any incoming packet toward its own IPv6 address, based on one of 359 multiple possible criteria: 361 o always 363 o an IP protocol (excluding IPv6 extension headers) 365 o for any standard transport protocol, a destination port number 367 o for IPsec ESP, an SPI value 369 Holes automatically expire if not refreshed before a negotiated 370 timeout. The gateway can additionally notify hosts through 371 unsolicited advertisements if it has rebooted or lost state. 373 4.4.2. Protocol Analysis 375 ALD is aimed at unmanaged IPv6 networks, where it might not be 376 acceptable to pass any unsolicited packets coming from the outside 377 toward any hosts in the internal network. ALD needs support from all 378 IPv6 routers within the network, because clients learn the ALD 379 middlebox address through IPv6 Neighbor Discovery auto-configuration. 380 It is expected that ALD will operate on the router itself in most 381 cases. As with IPv6 Neighbor Discovery, there is no authentication. 383 The specification is currently a work-in-progress; there is no known 384 deployment to date. Applications would supposedly need slight 385 modifications, similar as with [UPNP] or [I-D.cheshire-nat-pmp]. 387 ALD can handle "pinholes" for any transport protocol, although it is 388 limited to IPv6 networks, and is meant to restore the ability to 389 operate general-purpose servers behind stateful firewalls. It 390 currently does not explicitly support nesting, though ALD middleboxes 391 could probably forward pinholes request in a hierarchical manner 392 (from innermost to outermost device). 394 4.5. NLS - Network Layer Signaling Transport Layer 396 To be completed [I-D.shore-nls-fw]. 398 4.6. AFWC - Authorized IP Firewall Control Application 400 To be completed [I-D.shore-afwc]. 402 5. Security Considerations 404 This document is a survey of existing protocols and does not raise 405 any new security considerations. The security considerations of the 406 surveyed protocols are discussed in their respective specifications, 407 at least for protocols developed within the IETF. 409 6. IANA Considerations 411 This document raises no IANA considerations. 413 7. Acknowledgments 415 The authors would like to thank: Pasi Eronen. 417 8. Informative References 419 [I-D.cheshire-nat-pmp] 420 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 421 draft-cheshire-nat-pmp-02 (work in progress), 422 October 2006. 424 [I-D.ietf-nsis-nslp-natfw] 425 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 426 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in 427 progress), March 2007. 429 [I-D.shore-afwc] 430 Shore, M. and D. McGrew, "An Authorized IP Firewall 431 Control Application", draft-shore-afwc-00 (work in 432 progress), September 2006. 434 [I-D.shore-nls-fw] 435 Shore, M., "The NLS Firewall Application", 436 draft-shore-nls-fw-00 (work in progress), February 2006. 438 [I-D.wing-behave-nat-control-stun-usage] 439 Wing, D. and J. Rosenberg, "Discovering, Querying, and 440 Controlling Firewalls and NATs using STUN", 441 draft-wing-behave-nat-control-stun-usage-02 (work in 442 progress), June 2007. 444 [I-D.woodyatt-ald] 445 Woodyatt, J., "Application Listener Discovery (ALD) for 446 IPv6", draft-woodyatt-ald-01 (work in progress), 447 June 2007. 449 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 450 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 451 March 1996. 453 [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, 454 "Realm Specific IP: Protocol Specification", RFC 3103, 455 October 2001. 457 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 458 A. Rayhan, "Middlebox communication architecture and 459 framework", RFC 3303, August 2002. 461 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 462 Middlebox Configuration (SIMCO) Protocol Version 3.0", 463 RFC 4540, May 2006. 465 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 466 Device Control Protocol V 1.0", November 2001. 468 Authors' Addresses 470 Lars Eggert 471 Nokia Research Center 472 P.O. Box 407 473 Nokia Group FIN-00045 474 Finland 476 Phone: +358 50 4824461 477 Email: lars.eggert@nokia.com 478 URI: http://research.nokia.com/people/lars_eggert/ 480 Pasi Sarolahti 481 Nokia Research Center 482 P.O. Box 407 483 Nokia Group FIN-00045 484 Finland 486 Phone: +358 50 4876607 487 Email: pasi.sarolahti@nokia.com 488 URI: http://www.iki.fi/pasi.sarolahti/ 489 Remi Denis-Courmont 490 Nokia Technology Platforms 491 P.O. Box 407 492 Nokia Group FIN-00045 493 Finland 495 Phone: +358 50 4876315 496 Email: remi.denis-courmont@nokia.com 497 URI: http://www.remlab.net/ 499 Vlad Stirbu 500 Nokia Technology Platforms 501 P.O. Box 407 502 Nokia Group FIN-00045 503 Finland 505 Phone: +358 50 3860572 506 Email: vlad.stirbu@nokia.com 508 Full Copyright Statement 510 Copyright (C) The IETF Trust (2007). 512 This document is subject to the rights, licenses and restrictions 513 contained in BCP 78, and except as set forth therein, the authors 514 retain all their rights. 516 This document and the information contained herein are provided on an 517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 519 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 520 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 521 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 524 Intellectual Property 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed to 528 pertain to the implementation or use of the technology described in 529 this document or the extent to which any license under such rights 530 might or might not be available; nor does it represent that it has 531 made any independent effort to identify any such rights. Information 532 on the procedures with respect to rights in RFC documents can be 533 found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use of 538 such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository at 540 http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention any 543 copyrights, patents or patent applications, or other proprietary 544 rights that may cover technology that may be required to implement 545 this standard. Please address the information to the IETF at 546 ietf-ipr@ietf.org. 548 Acknowledgment 550 Funding for the RFC Editor function is provided by the IETF 551 Administrative Support Activity (IASA).