RFC 4057

IPv6 Enterprise Network Scenarios

📅 published June 2005, from ietf

Hey bestie, RFC 4057 is here 🦋

RFC 4057: IPv6 Enterprise Network Scenarios 🌸 by J. Bound, Ed. at Hewlett Packard, published June 2005. It's Informational, so it's guidance, not a standard. The title block doesn't list anything it obsoletes or updates. ✨

Status of This Memo 📝

okay so this memo just provides information for the Internet community. It does not specify an Internet standard of any kind 🙅‍♀️ and distribution is unlimited 💖

Copyright (C) The Internet Society (2005). 🎀

Abstract 🔮

bestie, this doc lays out the scenarios for IPv6 deployment inside enterprise networks 💼 It defines a small set of basic enterprise scenarios and includes pertinent questions so enterprise admins can refine their own deployment scenarios ✨ Enterprise deployment requirements are discussed in two lenses: coexistence with IPv4 nodes, networks and applications, and basic network infrastructure requirements for IPv6 deployment 🧚

The scenarios and requirements here are the basis for further analysis to figure out which coexistence techniques and mechanisms are needed for enterprise IPv6 deployment 🫶 The results of that analysis will be published in a separate document, so stay tuned 👑

Table of Contents 📚

1.  Introduction................................................... 2
2.  Terminology.................................................... 3
3.  Base Scenarios................................................. 4
    3.1.  Base Scenarios Defined................................... 4
    3.2.  Scenarios Network Infrastructure Components.............. 5
    3.3.  Specific Scenario Examples............................... 8
    3.4.  Applicability Statement..................................10
4.  Network Infrastructure Component Requirements..................10
    4.1.  DNS......................................................11
    4.2.  Routing..................................................11
    4.3.  Configuration of Hosts...................................11
    4.4.  Security.................................................11
    4.5.  Applications.............................................12
    4.6.  Network Management.......................................12
    4.7.  Address Planning.........................................12
    4.8.  Multicast................................................12
    4.9.  Multihoming..............................................12
5.  Security Considerations........................................12
6.  Normative References...........................................13
Acknowledgements...................................................13

1. Introduction ✨

okay this section is the setup, so let's get into it 💅 Same deal as the abstract: this doc describes the scenarios for IPv6 deployment within enterprise networks 🏢 It defines a small set of basic scenarios and includes pertinent questions so enterprise admins can refine their deployment plans 📋 Deployment requirements are looked at through coexistence with IPv4 nodes, networks and apps, plus basic network infrastructure needs for IPv6 🌈 The scenarios and requirements here will be the basis for more analysis on which coexistence techniques and mechanisms enterprise IPv6 deployment needs 🔍 That analysis gets published in a separate document 📄

The audience is the enterprise network team that's thinking about deploying IPv6 🫶 This doc is useful for enterprise teams who have to figure out the IPv6 transition strategy for their org 🦋 Those teams are expected to include people from management, network operations, and engineering 💼 The scenarios give an example set of cases the enterprise can use to build its own IPv6 network scenario 🧚

So the doc describes a set of scenarios, each with a network infrastructure, to frame the discussion 🎀 Honestly, it's impossible to define every enterprise scenario that will apply to IPv6 adoption and transition 😭

Each enterprise picks the transition that best supports its business requirements 💖 Trying to define a default or one-size-fits-all transition scenario simply will not work 🙅‍♀️ This doc also doesn't try to depict the drivers for an enterprise to adopt IPv6 🌸

It's hard to quantify every scenario an enterprise team has to plan for IPv6, but it is possible to depict a set of abstract scenarios that help with planning 🍓 This doc presents three base scenarios that enterprises can use as models when defining their specific scenarios 👑

Here's how the three go. Scenario one: the enterprise decides to deploy IPv6 alongside IPv4 🪞 Scenario two: the enterprise decides to deploy IPv6 because of a specific set of applications it wants to run over an IPv6 network 📱 Scenario three: the enterprise is building a new network or restructuring an existing one, and decides IPv6 is the predominant protocol inside the enterprise, coexisting with IPv4 🚀 After that, the doc briefly reviews a set of network infrastructure components that must be analyzed and are common to most enterprises 🔎

Then the doc gives three specific scenario examples that use those components to depict the requirements 💅 These are common enterprise deployment cases that show the challenges of transitioning a network to IPv6 🌈

Next up: supporting legacy functions on the network while the transition is in process, plus the infrastructure components the enterprise needs to analyze 🕰️ Interoperation with legacy functions inside the enterprise will be required for all transitions, except possibly for a new network that's IPv6 from inception 🌱 The infrastructure components show the functions in those networks that need consideration for IPv6 deployment and transition ⭐

Using the scenarios, infrastructure components, and examples in this doc, an enterprise can define its specific scenario requirements 💖 Once it understands the legacy functions and infrastructure components it needs, it can work out the network operations required to deploy IPv6 🛠️ The tools and mechanisms that support IPv6 deployment operations will need enterprise analysis 🔬 That analysis gets presented in subsequent document(s) 🫶

2. Terminology 📖

Here are the key terms, bestie. Don't skip this part, it matters 🙈

Enterprise Network - A network that has multiple internal links, one
                     or more router connections to one or more
                     Providers, and is actively managed by a network
                     operations entity.

Provider           - An entity that provides services and
                     connectivity to the Internet or other private
                     external networks for the enterprise network.

IPv6 Capable       - A node or network capable of supporting both
                     IPv6 and IPv4.

IPv4 only          - A node or network capable of supporting only
                     IPv4.

IPv6 only          - A node or network capable of supporting only
                     IPv6.  This does not imply an IPv6 only stack in
                     this document.

3. Base Scenarios 🎀

okay so three base scenarios are defined to capture the essential abstraction set for the enterprise 🧁 Each scenario has assumptions and requirements 📝 This isn't an exhaustive set of scenarios, just a base set of general cases 🌷

Quick heads-up: when this section says network infrastructure, it means the software, network operations and configuration, and methods used to operate a network in an enterprise 🛠️

For the base scenarios, it's assumed that any IPv6 node is IPv6 capable ✨

3.1. Base Scenarios Defined 🔥

Here's the scenario lineup, bestie 👑 Read the assumptions and requirements for each one carefully 💅

Scenario 1:   Wide-scale/total dual-stack deployment of IPv4 and IPv6
              capable hosts and network infrastructure.  Enterprise
              with an existing IPv4 network wants to deploy IPv6 in
              conjunction with their IPv4 network.

Assumptions:  The IPv4 network infrastructure used has an equivalent
              capability in IPv6.

Requirements: Do not disrupt existing IPv4 network infrastructure
              assumptions with IPv6.  IPv6 should be equivalent or
              "better" than the network infrastructure in IPv4.
              However, it is understood that IPv6 is not required to
              solve current network infrastructure problems, not
              solved by IPv4.  It may also not be feasible to deploy
              IPv6 on all parts of the network immediately.

Scenario 2:   Sparse IPv6 dual-stack deployment in IPv4 network
              infrastructure.  Enterprise with an existing IPv4
              network wants to deploy a set of particular IPv6
              "applications" (application is voluntarily loosely
              defined here, e.g., peer to peer).  The IPv6 deployment
              is limited to the minimum required to operate this set
              of applications.

Assumptions:  IPv6 software/hardware components for the application
              are available, and platforms for the application are
              IPv6 capable.

Requirements: Do not disrupt IPv4 infrastructure.

Scenario 3:   IPv6-only network infrastructure with some IPv4-capable
              nodes/applications needing to communicate over the IPv6
              infrastructure.  Enterprise deploying a new network or
              restructuring an existing network, decides IPv6 is the
              basis for most network communication.  Some IPv4
              capable nodes/applications will need to communicate
              over that infrastructure.

Assumptions:  Required IPv6 network infrastructure is available, or
              available over some defined timeline, supporting the
              enterprise plan.

Requirements: Interoperation and Coexistence with IPv4 network
              infrastructure and applications are required for
              communications.

3.2. Scenarios Network Infrastructure Components ✨

okay so this section is all about the network infrastructure that exists for those enterprise scenarios 🏢 it's NOT an exhaustive list, just a base one the enterprise can expand for their own deployment 💅 the components are presented as functions the enterprise must analyze as part of defining their specific scenario 🎀 and analyzing those functions is literally how you figure out which actions are required to deploy IPv6 🌸

Network Infrastructure Component 1 🌐

Enterprise Provider Requirements

  • Is external connectivity required?
  • One site vs. multiple sites and are they within different geographies?
  • Leased lines or VPNs?
  • If multiple sites, how is the traffic exchanged securely?
  • How many global IPv4 addresses are available to the enterprise?
  • What is the IPv6 address assignment plan available from the provider?
  • What prefix delegation is required by the Enterprise?
  • Will the enterprise be multihomed?
  • What multihoming techniques are available from the provider?
  • Will clients within the enterprise be multihomed?
  • Does the provider offer any IPv6 services?
  • Which site-external IPv6 routing protocols are required?
  • Is there an external data center to the enterprise, such as servers located at the Provider?
  • Is IPv6 available using the same access links as IPv4, or different ones?

Network Infrastructure Component 2 📱

Enterprise Application Requirements

  • List of applications in use?
  • Which applications must be moved to support IPv6 first?
  • Can the application be upgraded to IPv6?
  • Will the application have to support both IPv4 and IPv6?
  • Do the enterprise platforms support both IPv4 and IPv6?
  • Do the applications have issues with NAT v4-v4 and NAT v4-v6?
  • Do the applications need globally routable IP addresses?
  • Do the applications care about dependency between IPv4 and IPv6 addresses?
  • Are applications run only on the internal enterprise network?

Network Infrastructure Component 3 🧑‍💻

Enterprise IT Department Requirements

  • Who "owns"/"operates" the network: in house or outsourced?
  • Is working remotely (i.e., through VPNs) supported?
  • Are inter-site communications required?
  • Is network mobility used or required for IPv6?
  • What are the requirements of the IPv6 address plan?
  • Is there a detailed asset management database, including hosts, IP/MAC addresses, etc.?
  • What is the enterprise's approach to numbering geographically separate sites that have their own Service Providers?
  • What will be the internal IPv6 address assignment procedure?
  • What site internal IPv6 routing protocols are required?
  • What will be the IPv6 Network Management policy/procedure?
  • What will be the IPv6 QOS policy/procedure?
  • What will be the IPv6 Security policy/procedure?
  • What is the IPv6 training plan to educate the enterprise?
  • What network operations software will be impacted by IPv6?
    • DNS
    • Management (SNMP & ad-hoc tools)
    • Enterprise Network Servers Applications
    • Mail Servers
    • High Availability Software for Nodes
    • Directory Services
    • Are all these software functions upgradeable to IPv6?
    • If not upgradeable, then what are the workarounds?
    • Do any of the software functions store, display, or allow input of IP addresses?
    • Other services (e.g., NTP, etc.)
  • What network hardware will be impacted by IPv6?
    • Routers/switches
    • Printers/Faxes
    • Firewalls
    • Intrusion Detection
    • Load balancers
    • VPN Points of Entry/Exit
    • Security Servers and Services
    • Network Interconnect for Platforms
    • Intelligent Network Interface Cards
    • Network Storage Devices
    • Are all these hardware functions upgradeable to IPv6?
    • If not, what are the workarounds?
    • Do any of the hardware functions store, display, or allow input of IP addresses?
  • Are the nodes moving within the enterprise network?
  • Are the nodes moving outside and inside the enterprise network?

Network Infrastructure Component 4 📊

Enterprise Network Management System

  • Performance Management required?
  • Network Management applications required?
  • Configuration Management required?
  • Policy Management and Enforcement required?
  • Security Management required?
  • Management of Transition Tools and Mechanisms?
  • What new considerations does IPv6 create for Network Management?

Network Infrastructure Component 5 🦋

Enterprise Network Interoperation and Coexistence

  • What platforms are required to be IPv6 capable?
  • What network ingress and egress points to the site are required to be IPv6 capable?
  • What transition mechanisms are needed to support IPv6 network operations?
  • What policy/procedures are required to support the transition to IPv6?
  • What policy/procedures are required to support interoperation with legacy nodes and applications?

3.3. Specific Scenario Examples 🎀

okay this section presents a set of base scenario examples, and it's NOT an exhaustive list either 🙈 these examples were picked to add some clarity to the base scenarios by making them feel less abstract, like real enterprise life 💖 the example networks may use the scenarios depicted in 3.1 and the infrastructure components in 3.2, but there are no direct implications specifically within these example networks. Section 3.1, 3.2, and 3.3 should be used in unison for enterprise IPv6 deployment planning and analysis. bestie, that's the combo move 🫶

Example Network A:

A distributed network across a number of geographically separated campuses.

  • External network operation.
  • External connectivity required.
  • Multiple sites connected by leased lines.
  • Provider independent IPv4 addresses.
  • ISP does not offer IPv6 service.
  • Private Leased Lines no Service Provider used.

Applications run by the enterprise:

  • Internal Web/Mail.
  • File servers.
  • Java applications.
  • Collaborative development tools.
  • Enterprise Resource applications.
  • Multimedia applications.
  • Financial Enterprise applications.
  • Data Warehousing applications.

Internal network operation:

  • In house operation of the network.
  • DHCP (v4) is used for all desktops; servers use static address configuration.
  • The DHCP server that updates naming records for dynamic desktops uses dynamic DNS.
  • A web based tool is used to enter name to address mappings for statically addressed servers.
  • Network management is done using SNMP.
  • All routers and switches are upgradeable to IPv6.
  • Existing firewalls can be upgraded to support IPv6 rules.
  • Load balancers do not support IPv6, upgrade path unclear.
  • Peer-2-Peer Application and Security supported.
  • IPv4 Private address space is used within the enterprise.

Example Network B:

A bank running a large network supporting online transaction processing (OLTP) across a distributed multi-sited network, with access to a central database on a remote network from the OLTP network.

  • External connectivity not required.
  • Multiple sites connected by VPN.
  • Multiple sites connected by Native IP protocol.
  • Private address space used with NAT.
  • Connections to private exchanges.

Applications in the enterprise:

  • ATM transaction application.
  • ATM management application.
  • Financial Software and Database.
  • Part of the workforce is mobile and requires access to the enterprise from outside networks.

Internal Network Operation:

  • Existing firewalls can be upgraded to support IPv6 rules.
  • Load balancers do not support IPv6, upgrade path unclear.
  • Identifying and managing each node's IP address.

Example Network C:

A Security Defense, Emergency, or other Mission Critical network operation:

  • External network required at secure specific points.
  • Network is its own Internet.
  • Network must be able to absorb ad-hoc creation of sub-networks.
  • Entire parts of the network are completely mobile.
  • All nodes on the network can be mobile (including routers).
  • Network high-availability is mandatory.
  • Network must be able to be managed from ad-hoc location.
  • All nodes must be able to be configured from stateless mode.

Applications run by the Enterprise:

  • Multimedia streaming of audio, video, and data for all nodes.
  • Data computation and analysis on stored and created data.
  • Transfer of data coordinate points to sensor devices.
  • Data and Intelligence gathering applications from all nodes.

Internal Network Operations:

  • All packets must be secured end-2-end with encryption.
  • Intrusion Detection exists on all network entry points.
  • Network must be able to bolt on to the Internet to share bandwidth as required from Providers.
  • VPNs can be used, but NAT can never be used.
  • Nodes must be able to access IPv4 legacy applications over IPv6 network.

3.4. Applicability Statement 🔮

the specific network scenarios picked here are a base set of examples, meant to support further analysis of enterprise networks 🧚 this is not a complete set of scenarios, fr fr. Example Network C is a verifiable use case, BUT right now the scenario defines an early adopter of enterprise networks moving to IPv6 as the main protocol strategy (IPv6 Routing, Applications, Security, and Operations), treating IPv4 as legacy operations straight away in the transition strategy. so it may not represent many first-wave enterprise IPv6 deployments 😭 every enterprise planning team will need to make that call for themselves as IPv6 deployment evolves 💅

4. Network Infrastructure Component Requirements 🧱

the enterprise will need to figure out which network infrastructure components need enhancements or need to be added for an IPv6 deployment 🛠️ this infrastructure has to be analyzed and understood as a critical resource to manage, no cap. the list in this section is not exhaustive, but it has the essential components the enterprise should look at before getting into more fine-tuned requirements like QOS, PKI, or Bandwidth requirements for IPv6 💜 these components are only identified here, and their details get covered in the analysis document for enterprise scenarios. References currently available for components are provided too ✨

4.1. DNS 🌍

DNS will now have to support both IPv4 and IPv6 DNS records, and the enterprise will need to decide how DNS is managed, accessed, and secured 🔐 the full range of DNS operational issues is beyond the scope of this document, but DNS resolution and transport solutions for both IP protocols are influenced by the chosen IPv6 deployment scenario. so users need to look at all their current DNS IPv4 operations and check whether those operations are supported for IPv6 [DNSV6] 🎀

4.2. Routing 🛣️

okay so routing is literally going to need to handle both IPv4 and IPv6 routing protocols, interior and exterior, and the two have to coexist across the enterprise network 🫶 the enterprise needs to figure out its IPv6 routing topology, its ingress and egress points to provider networks, and which transition mechanisms it wants for IPv6 adoption. it also has to check which IPv6 transition mechanisms its upstream providers support 💅

4.3. Configuration of Hosts 🖥️

bestie, IPv6 brings stateless autoconfiguration in addition to stateful autoconfiguration, for configuring hosts inside the enterprise ✨ the enterprise has to pick the best host configuration method for its network, decide whether it's using stateless or stateful autoconfiguration, and figure out how autoconfiguration will work for DNS updates. it also needs to work out how prefix delegation happens from its upstream provider and how those prefixes get cascaded down to the enterprise IPv6 network 🌸 the policy for DNS or the choice of autoconfiguration is out of scope for this document [CONF, DHCPF, DHCPL], so those choices are on you, babe 🎀

4.4. Security 🔐

the security mechanisms IPv4 uses today need to keep working for IPv6 inside the enterprise ✨ IPv6 should create no new security concerns for IPv4 🙈 the whole security infrastructure the enterprise uses right now needs to be analyzed against the effect of IPv6 deployment, so everyone knows what IPv6 supports. users should look at the other current IPv6 network infrastructure security work going on in the IETF and across the industry, and they'll have to work with their platform and software providers to find out which IPv6 security network infrastructure components are supported 💜 the enterprise also has to decide its security filter and firewall requirements for IPv6. and the policy choices users make about security are beyond the scope of this document, so that's a whole other vibe 😭

4.5. Applications 📱

existing applications will need to be ported, or provide proxies, so they can support both IPv4 and IPv6 [APPS] 🦋

4.6. Network Management 📊

adding IPv6 network infrastructure components means the enterprise network operations center has to manage them 👑 users will need to work with their network management platform providers to see what's supported for IPv6 while they plan their adoption, and which tools exist to monitor the network. network management doesn't need to support both IPv4 and IPv6 and treat nodes as dual stacks, which is giving simplicity 🍓

4.7. Address Planning 🗺️

the address space inside the enterprise needs to be defined and coordinated with the enterprise's routing topology, no skipping that step 💖 it's also important to identify the pool of IPv4 address space the enterprise has available to help with IPv6 transition methods 🌈

4.8. Multicast 📡

enterprises using IPv4 Multicast services will need to think about how those services might be implemented operationally in an IPv6-enabled environment ✨

4.9. Multihoming 🌐

right now, current IPv6 allocation policies mandate that IPv6 address space gets allocated from the upstream provider 🫠 if an enterprise is multihomed, it will have to figure out how it wants to support multihoming. this is also an area of study inside the IETF and still a work in progress 🧚

5. Security Considerations 🚨😭

ngl this section is the main character of the whole doc 💀 read it slowly, bestie.

this document lists scenarios for deploying IPv6 in enterprise networks, and there are no security considerations associated with making such a list. phew 🌸

there will be security considerations for deploying IPv6 in each of these scenarios, though. they'll be addressed in the document that includes the analysis of each scenario, so keep your eyes peeled for that one 👀🔥

6. Normative References 📚

[DNSV6]  Durand, A., Ihren, J., and P. Savola, "Operational
         Considerations and Issues with IPv6 DNS", Work in Progress.

[CONF]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

[DHCPF]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
         M. Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003

[DHCPL]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
         Discovery (ND) Trust Models and Threats", RFC 3756, May
         2004.

[APPS]   Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
         Castro, "Application Aspects of IPv6 Transition", RFC 4038,
         March 2005.

Acknowledgements 🫶

the Authors would like to thank everyone who contributed: the IETF v6ops Working Group, Alan Beard, Brian Carpenter, Alain Durand, Bob Hinden, and Pekka Savola 💖 literal legends.

Authors' Addresses 💌

Yanick Pouffary (Chair of Design Team)
HP Competency Center
950, Route des Colles, BP027,
06901 Sophia Antipolis CEDEX
FRANCE

Phone: + 33492956285
EMail: Yanick.pouffary@hp.com


Jim Bound (Editor)
Hewlett Packard
110 Spitbrook Road
Nashua, NH 03062
USA

Phone: (603) 884-0062
EMail: jim.bound@hp.com


Marc Blanchet
Viagenie inc.
2875 boul. Laurier, bur. 300
Ste-Foy, Quebec, G1V 2M2
Canada

EMail: Marc.Blanchet@viagenie.qc.ca


Tony Hain
Cisco Systems
500 108th Ave. N.E. Suite 400
Bellevue, WA 98004
USA

EMail: alh-ietf@tndh.net


Paul Gilbert
Cisco Systems
1 Penn Plaza, 5th floor,
NY, NY 10119
USA

Phone: (212) 714-4334
EMail: pgilbert@cisco.com

Margaret Wasserman
ThingMagic
One Broadway
Cambridge, MA 02142
USA

Phone: (617) 758-4177
EMail: margaret@thingmagic.com


Jason Goldschmidt
Sun Microsystems
M/S UMPK17-103
17 Network Circle
Menlo Park, CA 94025
USA

Phone: (650) 786-3502
Fax:   (650) 786-8250
EMail: jason.goldschmidt@sun.com


Aldrin Isaac
Bloomberg L.P.
499 Park Avenue
New York, NY 10022
USA

Phone: (212) 940-1812
EMail: aisaac@bloomberg.com


Tim Chown
School of Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom

EMail: tjc@ecs.soton.ac.uk

Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Madrid, SPAIN

Phone: +34 91 151 81 99
Fax:   +34 91 151 81 98
EMail: jordi.palet@consulintel.es


Fred Templin
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA

Phone: (650) 625-2331
EMail: ftemplin@iprg.nokia.com


Roy Brabson
IBM
PO BOX 12195
3039 Cornwallis Road
Research Triangle Park, NC 27709
USA

Phone: (919) 254-7332
EMail: rbrabson@us.ibm.com

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 on 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 on the extent to which any license under such rights might or might not be available. it also doesn't represent that it has made any independent effort to identify any such rights. information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📜

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights 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, patent applications, or other proprietary rights that may cover technology required to implement this standard. please send that information to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌷

funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society, you're the real MVP 👑✨

📦 where this page comes from