Network Working Group S. Deering Request for Comments: 4007 Cisco Systems Category: Standards Track B. Haberman Johns Hopkins Univ T. Jinmei Toshiba E. Nordmark Sun Microsystems B. Zill Microsoft March 2005 IPv6 Scoped Address Architecture Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3 4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3 5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11 8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11 9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Textual Representation . . . . . . . . . . . . . . . . . . . 15 11.1. Non-Global Addresses . . . . . . . . . . . . . . . . 15 11.2. The <zone_id> Part. . . . . . . . . . . . . . . . . . 15 11.3. Examples. . . . . . . . . . . . . . . . . . . . . . . 17 11.4. Usage Examples. . . . . . . . . . . . . . . . . . . . 17 11.5. Related API . . . . . . . . . . . . . . . . . . . . . 18 11.6. Omitting Zone Indices . . . . . . . . . . . . . . . . 18 11.7. Combinations of Delimiter Characters. . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . 19 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 24 1] defines unicast site-local addresses, the IPv6 working group decided to deprecate the syntax and the usage  and is now investigating other forms of local IPv6 addressing. The usage of any new forms of
local addresses will be documented elsewhere in the future. Thus, this document intentionally focuses on link-local and multicast scopes only. 2]. 3]. The definitions of unicast address scopes (link-local and global) and multicast address scopes (interface-local, link-local, etc.) are contained in . 1]. For unicast addresses, this document discusses two defined scopes: o Link-local scope, for uniquely identifying interfaces within (i.e., attached to) a single link only. o Global scope, for uniquely identifying interfaces anywhere in the Internet. The IPv6 unicast loopback address, ::1, is treated as having link- local scope within an imaginary link to which a virtual "loopback interface" is attached. The unspecified address, ::, is a special case. It does not have any scope because it must never be assigned to any node according to . Note, however, that an implementation might use an implementation dependent semantics for the unspecified address and may want to allow the unspecified address to have specific scopes. For example, implementations often use the unspecified address to represent "any" address in APIs. In this case, implementations may regard the unspecified address with a given particular scope as representing the notion of "any address in the scope". This document does not prohibit such a usage, as long as it is limited within the implementation.
 defines IPv6 addresses with embedded IPv4 addresses as being part of global addresses. Thus, those addresses have global scope, with regard to the IPv6 scoped address architecture. However, an implementation may use those addresses as if they had other scopes for convenience. For instance,  assigns link-local scope to IPv4 auto-configured link-local addresses (the addresses from the prefix 169.254.0.0/16 ) and converts those addresses into IPv4-mapped IPv6 addresses in order to perform destination address selection among IPv4 and IPv6 addresses. This would implicitly mean that the IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration link-local addresses have link-local scope. This document does not preclude such a usage, as long as it is limited within the implementation. Anycast addresses  are allocated from the unicast address space and have the same scope properties as unicast addresses. All statements in this document regarding unicast apply equally to anycast. For multicast addresses, there are fourteen possible scopes, ranging from interface-local to global (including link-local). The interface-local scope spans a single interface only; a multicast address of interface-local scope is useful only for loopback delivery of multicasts within a single node; for example, as a form of inter- process communication within a computer. Unlike the unicast loopback address, interface-local multicast addresses may be assigned to any interface. There is a size relationship among scopes: o For unicast scopes, link-local is a smaller scope than global. o For multicast scopes, scopes with lesser values in the "scop" subfield of the multicast address (Section 2.7 of ) are smaller than scopes with greater values, with interface-local being the smallest and global being the largest. However, two scopes of different size may cover the exact same region of topology. For example, a (multicast) site may consist of a single link, in which both link-local and site-local scope effectively cover the same topological span.
Note that a zone is a particular instance of a topological region (e.g., Alice's site or Bob's site), whereas a scope is the size of a topological region (e.g., a site or a link). The zone to which a particular non-global address pertains is not encoded in the address itself but determined by context, such as the interface from which it is sent or received. Thus, addresses of a given (non-global) scope may be re-used in different zones of that scope. For example, two different physical links may each contain a node with the link-local address fe80::1. Zones of the different scopes are instantiated as follows: o Each interface on a node comprises a single zone of interface- local scope (for multicast only). o Each link and the interfaces attached to that link comprise a single zone of link-local scope (for both unicast and multicast). o There is a single zone of global scope (for both unicast and multicast) comprising all the links and interfaces in the Internet. o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators. Zone boundaries are relatively static features, not changing in response to short-term changes in topology. Thus, the requirement that the topology within a zone be "connected" is intended to include links and interfaces that may only be occasionally connected. For example, a residential node or network that obtains Internet access by dial-up to an employer's (multicast) site may be treated as part of the employer's (multicast) site-local zone even when the dial-up link is disconnected. Similarly, a failure of a router, interface, or link that causes a zone to become partitioned does not split that zone into multiple zones. Rather, the different partitions are still considered to belong to the same zone. Zones have the following additional properties: o Zone boundaries cut through nodes, not links. (Note that the global zone has no boundary, and the boundary of an interface- local zone encloses just a single interface.) o Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common.
o A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces. o Each zone is required to be "convex" from a routing perspective; i.e., packets sent from one interface to any other in the same zone are never routed outside the zone. Note, however, that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link ), a lower layer network of the tunnel can be located outside the zone without breaking the convexity property. Each interface belongs to exactly one zone of each possible scope. Note that this means that an interface belongs to a scope zone regardless of what kind of unicast address the interface has or of which multicast groups the node joins on the interface.
The assignment of zone indices is illustrated in the example in the figure below: --------------------------------------------------------------- | a node | | | | | | | | | | | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link Figure 1: Zone Indices Example This example node has five interfaces: A loopback interface to the imaginary loopback link (a phantom link that goes nowhere). Two interfaces to the same Ethernet link. An interface to a point-to-point link. A tunnel interface (e.g., the abstract endpoint of an IPv6-over- IPv6 tunnel , presumably established over either the Ethernet or the point-to-point link). It is thus attached to five interface-local zones, identified by the interface indices 1 through 5. Because the two Ethernet interfaces are attached to the same link, the node is only attached to four link-local zones, identified by link indices 1 through 4. Also note that even if the tunnel interface is established over the Ethernet, the tunnel link gets its own link index, which is different from the index of the Ethernet link zone.
Each zone index of a particular scope should contain enough information to indicate the scope, so that all indices of all scopes are unique within the node and zone indices themselves can be used for a dedicated purpose. Usage of the index to identify an entry in the Management Information Base (MIB) is an example of the dedicated purpose. The actual representation to encode the scope is implementation dependent and is out of scope of this document. Within this document, indices are simply represented in a format such as "link index 2" for readability. The zone indices are strictly local to the node. For example, the node on the other end of the point-to-point link may well use entirely different interface and link index values for that link. An implementation should also support the concept of a "default" zone for each scope. And, when supported, the index value zero at each scope SHOULD be reserved to mean "use the default zone". Unlike other zone indices, the default index does not contain any scope, and the scope is determined by the address that the default index accompanies. An implementation may additionally define a separate default zone for each scope. Those default indices can also be used as the zone qualifier for an address for which the node is attached to only one zone; e.g., when using global addresses. At present, there is no way for a node to automatically determine which of its interfaces belong to the same zones; e.g., the same link or the same multicast scope zone larger than interface. In the future, protocols may be developed to determine that information. In the absence of such protocols, an implementation must provide a means for manual assignment and/or reassignment of zone indices. Furthermore, to avoid performing manual configuration in most cases, an implementation should, by default, initially assign zone indices only as follows: o A unique interface index for each interface. o A unique link index for each interface. Then manual configuration would only be necessary for the less common cases of nodes with multiple interfaces to a single link or of those with interfaces to zones of different (multicast-only) scopes. Thus, the default zone index assignments for the example node from Figure 1 would be as illustrated in Figure 2, below. Manual configuration would then be required to, for example, assign the same link index to the two Ethernet interfaces, as shown in Figure 1.
--------------------------------------------------------------- | a node | | | | | | | | | | | | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link Figure 2: Example of Default Zone Indices As well as initially assigning zone indices, as specified above, an implementation should automatically select a default zone for each scope for which there is more than one choice, to be used whenever an address is specified without a zone index (or with a zone index of zero). For instance, in the example shown in Figure 2, the implementation might automatically select intf2 and link2 as the default zones for each of those two scopes. (One possible selection algorithm is to choose the first zone that includes an interface other than the loopback interface as the default for each scope.) A means must also be provided to assign the default zone for a scope manually, overriding any automatic assignment. The unicast loopback address, ::1, may not be assigned to any interface other than the loopback interface. Therefore, it is recommended that, whenever ::1 is specified without a zone index or with the default zone index, it be interpreted as belonging to the loopback link-local zone, regardless of which link-local zone has been selected as the default. If this is done, then for nodes with only a single non-loopback interface (e.g., a single Ethernet interface), the common case, link-local addresses need not be qualified with a zone index. The unqualified address ::1 would always refer to the link-local zone containing the loopback interface. All other unqualified link-local addresses would refer to the link-local zone containing the non-loopback interface (as long as the default link-local zone was set to be the zone containing the non-loopback interface).
Because of the requirement that a zone of a given scope fall completely within zones of larger scope (see Section 5, above), two interfaces assigned to different zones of scope S must also be assigned to different zones of all scopes smaller than S. Thus, the manual assignment of distinct zone indices for one scope may require the automatic assignment of distinct zone indices for smaller scopes. For example, suppose that distinct multicast site-local indices 1 and 2 are manually assigned in Figure 1 and that site 1 contains links 1, 2, and 3, but site 2 only contains link 4. This configuration would cause the automatic creation of corresponding admin-local (i.e., multicast "scop" value 4) indices 1 and 2, because admin-local scope is smaller than site-local scope. With the above considerations, the complete set of zone indices for our example node from Figure 1, with the additional configurations here, is shown in Figure 3, below. --------------------------------------------------------------- | a node | | | | | | | | | | | | /--------------------site1--------------------\ /--site2--\ | | | | /-------------------admin1--------------------\ /-admin2--\ | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link Figure 3: Complete Zone Indices Example Although the above examples show the zones being assigned index values sequentially for each scope, starting at one, the zone index values are arbitrary. An implementation may label a zone with any value it chooses, as long as the index value of each zone of all scopes is unique within the node. Zero SHOULD be reserved to represent the default zone. Implementations choosing to follow the recommended basic API  will want to restrict their index values
to those that can be represented by the sin6_scope_id field of the sockaddr_in6 structure. Section 10). That routing table is restricted to refer to interfaces belonging to that zone.
o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded. Additionally, if the packet's destination address is a unicast address, an ICMP Destination Unreachable message  with Code 2 ("beyond scope of source address") is sent to the source of the original packet. Note that Code 2 is currently left as unassigned in , but the IANA will re-assign the value for the new purpose, and  will be revised with this change. Note that even if unicast site-local addresses are deprecated, the above procedure still applies to link-local addresses. Thus, if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol ). The forwarded packet may be transmitted back through the arrival interface, or through any other interface attached to the same link. A node that receives a packet addressed to itself and containing a Routing Header with more than zero Segments Left (Section 4.4 of ) first checks the scope of the next address in the Routing Header. If the scope of the next address is smaller than the scope of the original destination address, the node MUST discard the packet. Otherwise, it swaps the original destination address with the next address in the Routing Header. Then the above forwarding rules apply as follows: o The zone of the new destination address is determined by the scope of the next address and the arrival interface of the packet. The next-hop interface is chosen as per the first bullet of the rules above. o After the next-hop interface is chosen, the zone of the source address is considered as per the second bullet of the rules above. This check about the scope of the next address ensures that when a packet arrives at its final destination, if that destination is link-local, then the receiving node can know that the packet
originated on-link. This will help the receiving node send a "response" packet with the final destination of the received packet as the source address without breaking its source zone. Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary in the previously used next address field. For example, consider a case in which a link-border node (e.g., a router) receives a packet with the destination being a link-local address, and the source address a global address. If the packet contains a Routing Header where the next address is a global address, the next- hop interface to the global address may belong to a different link than that of the original destination. This is allowed because the scope of the next address is not smaller than the scope of the original destination.
* * * * * =========== Organization X * * | | * * | | * +-*----|-------|------+ * | * intf1 intf2 | * | * | * | * intf3 --- * | * | * | *********************************** | | | Router | | | ********************** ********************** | * * | Org. Y --- intf4 * * intf5 --- Org. Z | * * | ********************** ********************** +---------------------+ Figure 4: Multi-Organization Multicast Router As an example, the router in Figure 4 must exchange routing information on five interfaces. The information exchanged is as follows (for simplicity, multicast scopes smaller or larger than the organization scope except global are not considered here): o Interface 1 * All global groups * All organization groups learned from Interfaces 1, 2, and 3 o Interface 2 * All global groups * All organization groups learned from Interfaces 1, 2, and 3 o Interface 3 * All global groups * All organization groups learned from Interfaces 1, 2, and 3 o Interface 4 * All global groups * All organization groups learned from Interface 4 o Interface 5 * All global groups * All organization groups learned from Interface 5
By imposing route exchange rules, zone integrity is maintained by keeping all zone-specific routing information contained within the zone. Section 6, the <zone_id> part of this format does not have to contain the scope. This is because the <address> part should specify the appropriate scope. This also means that the <zone_id> part does not have to be unique among all scopes.
With this loosened property, an implementation can use a convenient representation as <zone_id>. For example, to represent link index 2, the implementation can simply use "2" as <zone_id>, which would be more readable than other representations that contain the "link" scope. When an implementation interprets the format, it should construct the "full" zone index, which contains the scope, from the <zone_id> part and the scope specified by the <address> part. (Remember that a zone index itself should contain the scope, as specified in Section 6.) An implementation SHOULD support at least numerical indices that are non-negative decimal integers as <zone_id>. The default zone index, which should typically be 0 (see Section 6), is included in the integers. When <zone_id> is the default, the delimiter characters "%" and <zone_id> can be omitted. Similarly, if a textual representation of an IPv6 address is given without a zone index, it should be interpreted as <address>%<default ID>, where <default ID> is the default zone index of the scope that <address> has. An implementation MAY support other kinds of non-null strings as <zone_id>. However, the strings must not conflict with the delimiter character. The precise format and semantics of additional strings is implementation dependent. One possible candidate for these strings would be interface names, as interfaces uniquely disambiguate any scopes. In particular, interface names can be used as "default identifiers" for interfaces and links, because by default there is a one-to-one mapping between interfaces and each of those scopes as described in Section 6. An implementation could also use interface names as <zone_id> for scopes larger than links, but there might be some confusion in this use. For example, when more than one interface belongs to the same (multicast) site, a user would be confused about which interface should be used. Also, a mapping function from an address to a name would encounter the same kind of problem when it prints an address with an interface name as a zone index. This document does not specify how these cases should be treated and leaves it implementation dependent. It cannot be assumed that indices are common across all nodes in a zone (see Section 6). Hence, the format MUST be used only within a node and MUST NOT be sent on the wire unless every node that interprets the format agrees on the semantics.
Hence, we have to login R1 first and then try to login R2 by using link-local addresses. In this case, we have to give the link-local address of R2 to, for example, telnet. Here we assume the address is fe80::2. Note that we cannot just type % telnet fe80::2 here, since R1 has more than one link and hence the telnet command cannot detect which link it should try to use for connecting. Instead, we should type the link-local address with the link index as follows: % telnet fe80::2%3 where "3" after the delimiter character `%' corresponds to the link index of the point-to-point link. 11]. Section 6, in some common cases with the notion of the default zone index, there can be no ambiguity about scope zones. In such an environment, the implementation can omit the "%<zone_id>" part. As a result, it can act as though it did not support the extended format at all. 1] also defines the syntax of IPv6 prefixes. If the address portion of a prefix is non-global and its scope zone should be disambiguated, the address portion SHOULD be in the format. For example, a link-local prefix fe80::/64 on the second link can be represented as follows: fe80::%2/64
In this combination, it is important to place the zone index portion before the prefix length when we consider parsing the format by a name-to-address library function . That is, we can first separate the address with the zone index from the prefix length, and just pass the former to the library function. The preferred format for literal IPv6 addresses in URLs is also defined . When a user types the preferred format for an IPv6 non-global address whose zone should be explicitly specified, the user could use the format for the non-global address combined with the preferred format. However, the typed URL is often sent on the wire, and it would cause confusion if an application did not strip the <zone_id> portion before sending. Note that the applications should not need to care about which kind of addresses they're using, much less parse or strip out the <zone_id> portion of the address. Also, the format for non-global addresses might conflict with the URI syntax , since the syntax defines the delimiter character (`%') as the escape character. This conflict would require, for example, that the <zone_id> part for zone 1 with the delimiter be represented as '%251'. It also means that we could not simply copy a non-escaped format from other sources as input to the URI parser. Additionally, if the URI parser does not convert the escaped format before passing it to a name-to-address library, the conversion will fail. All these issues would decrease the benefit of the textual representation described in this section. Hence, this document does not specify how the format for non-global addresses should be combined with the preferred format for literal IPv6 addresses. In any case, it is recommended to use an FQDN instead of a literal IPv6 address in a URL, whenever an FQDN is available.
allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised. Since the use of the textual representation of non-global addresses is restricted to use within a single node, it does not create a security vulnerability from outside the node. However, a malicious node might send a packet that contains a textual IPv6 non-global address with a zone index, intending to deceive the receiving node about the zone of the non-global address. Thus, an implementation should be careful when it receives packets that contain textual non- global addresses as data. Section 11 as a co-author of a separate proposal.  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.  Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
 Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.  Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of Link-Local IPv4 Addresses", Work in Progress.  Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.  Gilligan, R., "Scoped Address Extensions to the IPv6 Basic Socket API", Work in Progress, July 2002.  Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005.
Brian D. Zill Microsoft Research One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1-425-703-3568 Fax: +1-425-936-7329 EMail: email@example.com
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.