]> SAP SE

philipp@tiesel.net philipp.tiesel@sap.com

Google

furry13@gmail.com furry@google.com

University of New Hampshire Interoperability Labs

kouellette@iol.unh.edu

University of New Hampshire Interoperability Labs

bpatton@iol.unh.edu

Operations and Management v6ops IPv6 Applications Testing This document provides guidance for application developers and software as a service providers on how to approach IPv6 testing in Dual-stack (IPv4+IPv6), and IPv6-only scenarios, including "IPv6-only-strict" scenarios without any connectivity towards any relevant IPv4 endpoint. It discusses common misconceptions about the degree to which operating systems and libraries can abstract IPv6 issues away and explains common regressions to avoid when deploying IPv6 support. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction For the last 20 years, enabling applications for IPv6 has focused on coexistence with IPv4 and allowing traffic to shift towards IPv6 without breaking IPv4 operation. This target has changed in part due to a series of national regulations mandating state entities to proceed in the migration to IPv6, e.g., in China , the United States of America , Germany , and the Czech Republic . IPv6 support today means being fully functional in the absence of IPv4 and transition technologies providing connectivity to the IPv4 Internet. Therefore, today's applications are expected to function regardless of whether they are used in an IPv4-only environment, a Dual-stack environment, or an IPv6-only environment, with or without connectivity to the IPv4 Internet. To achieve this, applications need to be verified against all these scenarios. While the availability of IPv6 support in applications has a considerable impact on the success of IPv6, there exists no documented best current practices how to do so. Testing IPv6 compliance of network gear and operating systems has been documented extensively. While the IETF does not define compliance tests, best current practice exists for the behavior of general IPv6 nodes and Customer Edge (CE) routers . To fill that gap, this document provides guidance for application developers and cloud application providers on how to approach IPv6 testing. It describes which scenarios they should consider validating against, and which common regressions to avoid when adding IPv6 support. While many application developers assume that the network abstractions of the operating system (OS), communication libraries, and application frameworks will handle the transition towards IPv6 transparently, leaky abstractions within these frameworks will make it difficult for an application developer to write address family-independent code for features such as allow/deny lists and logging. In addition to that challenge, modern cloud applications are typically composed of hundreds to thousands of micro and macroservices, forming a complex distributed system that requires intricate communication and orchestration infrastructure to operate. Enabling these applications to communicate over IPv6 requires careful analysis of data flows within all services and proper IPv6 support in all components that may require IPv6 traffic, as well as IPv6 addresses as metadata.

Conventions and Definitions

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Base Connectivity Scenarios Within this document, we define the following four "base connectivity scenarios" in which applications ought to be verified for availability and functional correctness.

IPv4-only:

A node or application that has native connectivity towards all endpoints relevant for the test scenario using IPv4 and no connectivity towards any relevant IPv6 endpoints.

Dual-stack:

A node or application that has native connectivity towards all endpoints relevant for the test scenario using IPv4 as well as using IPv6.

IPv6-only with NAT64:

A node or application that has native connectivity towards all endpoints relevant for the test scenario using IPv6 and connectivity towards IPv4 endpoints using a transition technology like NAT64, e.g., NAT64 in combination with CLAT, DNS64, or local address synthesis.

IPv6-only-strict:

A node or application that has native connectivity towards all endpoints relevant for the test scenario using IPv6 and no connectivity towards any relevant IPv4 endpoints, neither encapsulated nor translated. This definition slightly diverges from the one in as it ignores IPv4 connectivity to anywhere outside the testing scope.

Lifecycle Functions Orthogonal to the Base Scenarios, we define lifecycle functions, i.e., the phases in which an application is approached during a simplified lifecycle of the application, in accordance to as follows:

• Installation: The installation of the application including any initial configuration required for getting the application in a state where remote services are operational.
• User Interface: All forms of interactive access to the application (e.g., Web UI, API).
• Management: All forms of remote management and monitoring functions.
• Update: All forms of update functions, including both automatic and manual update mechanisms.

Testing Objectives As a basic principle, IPv6 application testing should always be derived from functional and integration testing. Therefore, the goal is to verify that the expected behavior is consistent across all connectivity scenarios, i.e., the application functions correctly in IPv4-only, Dual-stack, IPv6-only with NAT64 and IPv6-only-strict settings. The following sections provide guidance on which connectivity scenarios to include in a testing campaign and how to approach testing complex cloud applications.

Connectivity Scenarios lists the combinations of connectivity scenarios that application testing should generally consider. Note, while the involved parties are listed here as "client" and "server" to reflect the most common case, the combinations can be used the same way when considering peer-to-peer applications – with "client" representing the initiating or first acting party. The first five scenarios marked as base should cover all major code paths and fallback conditions. These include Dual-stack clients combined with IPv4-only and IPv6-only-strict servers, to test whether the additional address family confused the client. We also include the cases with Dual-stack Server and Single-Stack clients, to test whether a single address family at client side works as anticipated and look at the transition case using NAT64. We have no special scenarios for 464XLAT and IPv6-Mostly , as these architectures are from the client side indistinguishable from the Dual-stack (464XLAT or IPv6-Mostly with CLAT) or IPv6-only with NAT64 (IPv6-Mostly without CLAT). MTU issues, as described in Section 7.4.5, that may arise form these scenarios are covered in . We also do not separate IPv4-only cases with and without NAT, despite the fact that applications exist that assume NAT for IPv4 and do not work without, as these issues are also revealed by the IPv6 scenarios. For the IPv6-only datacenter case, where servers may be exposed to the IPv4-only Internet using NAT64, it is also advisable to consider the case marked as IPv6-only-DC in . The other combinations are unlikely to exhibit additional problems for client-server-based applications and therefore are marked as extended in . For peer-to-peer applications and applications with complex connection handling like using STUN or TURN , skipping these scenarios is strongly discouraged. Connectivity scenario combinations to consider

Client	Server	Classification
Dual-stack	IPv4-only	base
Dual-stack	IPv6-only-strict	base
IPv4-only	Dual-stack	base
IPv6-only with NAT64	IPv4-only	base
IPv6-only-strict	Dual-stack	base
IPv4-only	IPv6-only with NAT64	IPv6-only-DC
Dual-stack	Dual-stack	extended
IPv4-only	IPv4-only	extended
IPv6-only with NAT64	IPv6-only-strict	extended
IPv6-only-strict	IPv6-only-strict	extended

Testing with Intermediaries (e.g., Proxies) Many application protocols support communicating across intermediates, most commonly HTTP, HTTP-Connect, SOCKS, or MASQUE proxies. Peer-to-peer applications often support TURN as an intermediary to traverse NAT and provide connectivity between IPv4-only and IPv6-only hosts. When testing connectivity scenarios for such an application, additional test cases including a proxy are recommended. As a proxy can convert between address families, all combinations shown in , consisting of base scenarios towards the proxy and (assuming the same scenarios on both sides of the proxy) the respective base scenarios from the proxy to the server, should be considered for testing. Base scenario combinations including a proxy to consider for IPv6 testing

Client	Proxy	Server
Dual-stack	IPv4-only	Dual-stack
Dual-stack	IPv6-only-strict	Dual-stack
IPv4-only	Dual-stack	IPv4-only
IPv4-only	Dual-stack	IPv6-only-strict
IPv6-only with NAT64	IPv4-only	Dual-stack
IPv6-only-strict	Dual-stack	IPv4-only
IPv6-only-strict	Dual-stack	IPv6-only-strict

Testing Name Resolution Issues As most applications use name resolution to bootstrap their connectivity, it is necessary to consider name resolution aspects when testing IPv6 readiness. While some name resolution issues only manifest in certain connectivity scenarios or can be mitigated by using Happy Eyeballs /, others will just map to different connectivity scenarios. In this section, we list name resolution issues to consider for testing.

Missing DNS Records While a server endpoint is intended to support dual-stack connectivity, the A or AAAA DNS records for the endpoint may be missing, e.g., due to misconfiguration or broken tooling, or does not reach the client endpoint, e.g., because it got filtered out by a middle box or local resolver. The same can happen for names discovered and resolved through mDNS . While deployment and integration testing should try to test for this kind of broken connectivity, this scenario is usually indistinguishable from an IPv4-only or an IPv6-only server endpoint, and therefore already addressed by testing the base scenarios above.

Incorrect DNS Records Independent of the deployed server endpoint, there may be an A and AAAA record either pointing somewhere else, e.g., to an old or planned deployment. For either IPv4-only or IPv6-only-strict clients, this scenario should always fail. For Dual-stack clients, it should be tested whether they can use the working IPv4-only or IPv6-only connectivity scenario, either by using Happy Eyeballs / or trying the next resolved address candidate after timeout. Especially for the latter, it is advisable to verify whether the connection delay is acceptable of the desired use-case. IPv6-only clients with NAT64 are only expected to work with broken AAAA records when deployed with CLAT (should behave like Dual-stack as discussed in Section ) or local NAT64 address, e.g., as when implementing Happy Eyeballs v2 . IPv6-only clients with NAT64 that rely on DNS64 only are expected to fail as the presence of AAAA records prevents synthesis of DNS64 records. Testing with IPv4-Mapped IPv6 Addresses in AAAA records is also recommended. While this makes zero sense, it has been seen in the wild and should not confuse the client.

DNS delegation issues Integration testing for Cloud applications should verify that the necessary domain names are resolvable from IPv4-only or IPv6-only-strict DNS resolvers. describes misconfigurations that may prevent this and should be prevented.

Testing with IP literals Most name resolution libraries support IP literals, i.e., textual representations of IP addresses. Applications should be tested to determine whether they work as expected with IPv4 literals and all IPv6 address representations described in . If there is a use-case for link-local communication using IP literals, it should be tested whether the zone identifier can be entered as described in and work as expected.

Testing with Partially Broken Connectivity, MTU, and Fragmentation Issues When multiple address families are available, network packets may traverse different paths depending on the address family. Even when the same path is traversed, the path can exhibit distinct behaviors, e.g., dropping all or particular packets, especially in the presence of middle-boxes. From the communication endpoints that are expected to be reachable using both address families, some may only be reachable by one address family, while others may only be reachable by the other. Testing applications against these scenarios can become a key enabler for users' acceptance of IPv6, especially during a transition phase where partially broken connectivity is expected more frequently. In some cases, connectivity issues may only become apparent late in the communication process, for example, after a successful TCP handshake but before a TLS handshake succeeds. In such scenarios, clients restricted to a single address family — such as IPv6-only-strict clients — may experience complete loss of connectivity in these scenarios, while dual-stack clients often mask such failures by automatically falling back to another address family. In addition to partial blackholing, MTU issues may be limited to one address family or behave differently with respect to aspects like MTU available, dropping of fragmented packets, and ICMP messages generated. As only IPv4 supports on-path fragmentation, IPv6 is more dependent on working ICMP packet too big reporting. It is advisable to test for partial blackholing and MTU issues during deployment and integration testing by testing with IPv4-only and IPv6-only-strict clients to detect such blackholes. In case these issues can occur outside the testers' circle of control, it is advisable to simulate this type of failure and ensure that the application's behavior supports the detection and analysis of these errors.

Testing without IPv4 Loopback Addresses (127.0.0.0/8) Some applications and services may assume the existence and reachability of the IPv4 loopback addresses (127.0.0.0/8) when binding to a socket or for communicating with other services on the same host. For example, a web server may explicitly listen on a 127.0.0.0/8 by default. For IPv6-only-strict scenarios, system administrators may choose to disable IPv4, including loopback. In such cases, applications may fail to operate correctly. Applications expecting to bind to an IPv4 loopback address may fail to start when these addresses are unavailable due to a bind failure. Applications expecting these addresses to be available for inter-service communication will result in these services being unable to communicate properly. Because of this, when testing applications for the IPv6-only-strict scenario, it is recommended to test the application in an environment without IPv4 on the loopback interface.

Testing Lifecycle Function Considerations To cover the whole lifecycle of an application including installation, user interface, management, and update, it is recommended to test that the lifecycle functions defined in are operational within the connectivity scenarios defined in . Testing the normal operations of the application is encompassed by the user interface lifecycle function. In particular, keep the following considerations in mind:

• Installation: Installation may require communications with remote first-party services (e.g., activation/license server) or remote third-party services (e.g., package repositories). In these scenarios, the installer acts as the client, and the remote service acts as the server. In cases of remote third-party services, testing all server scenarios in may not be feasible, and impact the client scenarios that can be supported. For example, if a third-party service is IPv4-only, testing an IPv6-only-strict scenario will fail.
• User Interface: User interfaces can be incredibly complex with numerous contexts, views, API endpoints, CLI commands, etc. When testing an application's user interface(s), the normal operations of the application should be verified. Additionally, when testing non-web-based user interfaces, it is recommended to test components of the interface that involve communications with remote services, and those that handle network configuration parameters. For example, a network configuration interface may only accept IPv4 address literals for certain parameters. For testing web-based user interfaces, see .
• Management: Depending on the application, management functions may be provided via the user interface. However, the application may have additional management functions (e.g., SNMP, syslog, etc.) that should be tested. As the source triggering application behavior is crucial for logging and auditing functionality, addresses recorded need to be verified to be represented correctly. See Section about representation of addresses.
• Update: Depending on the application, update functions may be exercised during installation. However, the application may have additional update functions (e.g., automatic updates, manual update mechanisms, etc.) that should be tested.

Testing Complex Cloud Applications and Applying Test Cases When testing complex applications, especially cloud applications, they typically involve many data flows. An application or component may be considered as a server for some of these, while being a client in others. Therefore, test cases need to cover each data flow in all relevant scenarios. As functional and integration tests are often defined as end-to-end test cases, they often involve several components, e.g., micro-services, load-balancers, application gateways, logging, authentication, and authorization services, which use IP-based protocols between the components. Therefore, an end-to-end test case breaks down to a series of flows between components, and for each of these flows, we need to determine whether we need to apply the connectivity scenarios from to it, or whether the connectivity scenarios are only controlled by the deployment of the application. For external flows, i.e., flows outside the developers' control, usually all base scenarios from need to be accounted for. If one side of the flow is under administrative control, the number of scenario combinations can still be limited: For example, a cloud software provider choosing to deploy Dual-stack endpoints can skip all non-Dual-stack cases on the respective side of the communication. For internal flows, the relevant scenarios only depend on the applications' architecture, and only scenarios planned in the deployment need to be considered. From a networking perspective, flows between components are typically independent, as long as endpoints are not signaled inside of the protocol. There is no need to run the Cartesian product of scenarios x communications as long as all relevant scenarios for a given flow are tested. In addition to the data flows, an implementation may include metadata about the data flow when communicating with backend systems, e.g., for logging or authorization purposes. While the flows towards these backend systems themselves may be safe to ignore as outlined above, the functional correctness of the backend systems for all kinds of IP address need to be verified as part of the test series. Ignoring IP addresses as data in the testing may result in malfunctions, like always denying access over IPv6, or security issues, like not logging access from IPv6 clients.

Special considerations for Web-based Applications Web-based applications usually load resources from multiple parties, including CDNs and analytic tools, involving data flows to all these parties. When facing the requirement to support IPv6-only-strict users, being unable to load some resources due to missing/defective IPv6 support at the respective parties can have effects from missing analytics insights or ad revenue to severe functional defects rendering the application unusable. When testing such applications, it is not sufficient to only focus on the initial/main interactions, but it is necessary to consider all resources and parties providing them. As Web browsers load these resources dynamically and third-party resources may themselves may request resources from more parties, this kind of testing usually requires an instrumented Web browser, e.g., using .

Considerations for Addresses as Data When applications process IP addresses as data, e.g., as part of logging or management functionality, this functionality needs to work for all possible address families and representations. One challenge to consider is that the textual representation of IPv4 and IPv6 addresses are not canonical. It allows several valid textual representations for the same address, which makes direct string comparison and arithmetic operations on addresses error-prone and slow. For example, the IPv6 address 2001:db8::1 can be written as 2001:db8:0:0:0:0:0:1, 2001:0db8::0.0.0.1, or in several other forms. While custom logic to check, parse and process addresses is often error-prone and should be validated thoroughly, modern environments and frameworks usually provide data structures that encapsulate the canonical binary representation and include methods for parsing the various textual representations, comparing addresses, performing subnet operations, and rendering addresses in a consistent format. For situations where textual representation of IPv6 addresses is needed — such as in user interfaces, logging output, and text-based data formats like JSON, YAML, TOML, and XML — provides recommendations on which of the valid textual representations should be used. Applications should be tested whether they follow when rendering IPv6 addresses in textual form, as required by national regulations like , while accepting all valid representations defined in .

Testing Strategies Naïve IPv6 testing, based on end-to-end functional tests as outlined in , would require running a set of functional tests in various connectivity scenarios. In certain environments, setting up test cases for all scenarios can become forbiddingly expensive, especially for complex cloud applications, application platforms, or when dealing with corporate IT environments. In this section, we give recommendations how to set up scenarios defined in and present strategies to meet the relevant testing objective by modifying Dual-stack clients and servers to conclude the results for other scenario combinations, e.g., by tracing whether the right address family is used.

IPv6-only-strict Clients This is the most natural way to test whether IPv6-only-strict clients behave correctly. The client device is either placed in a network without IPv4 connectivity or the IPv4 stack is disabled on the device while it is in a Dual-stack network. While most desktop operating systems allow disabling IPv4, mobile operating systems, such as Android and iOS, do not. For mobiles operating systems, an IPv6-only-strict environment is needed. In both cases, it has to be ensured that there is no way to access IPv4-only resources. In particular, fallback to NAT64 must be prevented by disabling CLAT , making sure DNS resolution does not perform DNS64 address synthesis and blocking the well-known NAT64 prefix for these clients. In addition, VPN services including privacy services like need to be disabled as they can provide connectivity towards the IPv4 Internet. A note on the applicability of disabling IPv4: Before disabling IPv4 make sure the environment supports IPv6-only operation. Many desktop virtualization environments become unusable because IPv4 is needed to access and manage the virtual machines. Some corporate environments may render the machines unusable as they require IPv4 connectivity for sign-on.

IPv6-only Servers IPv6-only servers are a good option when setting up an IPv6-only-strict client environment is infeasible and clients are know to only contact a single server or a small number of servers under the testers' control. Even if setting up an IPv6-only-strict server environment is infeasible, most testing is also achievable by setting up a dedicated DNS name only containing an AAAA record pointing to the IPv6 addresses of an otherwise Dual-stack server.

Client-based tracing If we can't limit the available address families, we can still trace and verify whether the address family desired for the scenario is used. Client-based tracing is especially useful when Dual-stack servers and clients are available and a conclusion for the IPv6-only-strict case is desired. By using the clients' logging/tracing/debugging functionality, the tester can verify that the actual data flows happen over IPv6, which is preferred by most network abstractions. If the client allows changing the preference between IPv6 and IPv4, IPv4-only testing is also possible. The most relevant case for this strategy is testing Web applications. By examining the Web browsers' performance log or using a plugin like that visualizes connectivity information, the tester can determine whether all resources are available using IPv6.

Server-based tracing Analogue to tracing on the client side, it is also possible to look at the protocols used on the server side. While this is functionally equivalent for protocols where clients only communicate to a single server, this approach is not feasible for Web-based applications where a client usually needs flows towards many servers, where client or network based tracing are the only feasible alternatives to testing with an IPv6-only-strict client.

Network-based tracing If the communication pattern of an application is known well enough, a packet tracer as allows to verify that an application in a Dual-stack environment uses IPv6 for all of its flows. If this can be verified, failures in IPv6-only-strict environments are unlikely. While this is the least invasive method of testing IPv6-only-strict scenarios in a Dual-stack setup, it is the most error-prone as it requires the tester to fully understand the network flows of the application and requires the skills to interpret the output of a packet tracer.

Common Sources of IPv6 Related Failures and Misbehavior In this section, we discuss special failure modes that can cause unexpected application behavior that is hard to debug. While some of these cases can be automatically mitigated, especially through generalizing the concept of Happy Eyeballs , others may not. In cases that developers choose not to mitigate erroneous application behavior, users and operators should be supported in the resolution by exposing specific and detailed error or debug messages.

Enable IPv6 Feature Gates Some applications completely ignore IPv6 unless explicitly configured to enable IPv6. This adds another class of user or configuration errors, like deploying an application without enabled IPv6 support in an IPv6-only environment. As these feature gates are often buried deeply in the documentation and are often vendor, product, or component specific, every component needs to be checked to determine whether IPv6 support needs extra configuration.

Ignore Management and Control Interfaces Ignoring management and control interfaces when enabling and testing applications for IPv6-only operation turns out to be a common pattern. As already discussed in , special care should be taken to cover all of these flows and avoid setups that require dual-stack deployment.

Destination Address Selection Preference and Address Filtering The destination address selection algorithm in filters unavailable address families (Rule 1) and de-prioritizes non-matching address families (Rule 2) and clearly prioritizes IPv6 GUA addresses over IPv4 addresses. While most operating systems and some alternative resolver libraries, such as , implement or its predecessors / correctly, there are a number of notable and widely used implementations that implement something else, causing anything from unexpected behavior to hard-to-debug errors.

• Most JAVA runtimes do the opposite and prefer IPv4 destinations over IPv6. To prefer IPv6 addresses over IPv4, one needs to set the system property java.net.preferIPv6Addresses=true.
• Some applications only use the first address candidate from the getaddrinfo() and fail if the connection attempt to that one fails.
• Applications composed of services built on different programming languages or runtimes may behave inconsistently with regard to choosing destination addresses.
• NGINX (at the time of writing, since at least version 1.6 and unchanged in 1.31) has its own user DNS resolver without address filtering; thus, adding a AAAA record to a backend can render that backend unusable. After having resolved a AAAA record, it is trying to open an IPv6 socket, even when the IPv6 stack is disabled. As socket creation failure is not expected, an internal server error is sent back to the client.
• Some resolvers ignore address families for which no default route exists or where the default-route is pointing to an unsupported/ignored device. This becomes cumbersome especially in split-VPN use cases, e.g. when trying to contact IPv6-only endpoints via the VPN while having IPv4-only Internet connectivity.

Listening on only one Address Family Many tutorials and programmer facing documentation have still not been updated to cover listening on multiple address families to accept connections from both IPv6 and IPv4. Listening code should be checked to determine whether it either opens distinct listening sockets for IPv6 as well as for IPv4 or configures IPv6 sockets also to bind to IPv4, e.g. by setting IPV6_V6ONLY socket option on Linux to zero. In deployments, always use tools like netstat or lsof to verify both address families are listened on if needed.

Input Validation and Output Rendering While most libraries and application frameworks have decent IPv6 support, there often is still application logic that prevents taking advantage of the IPv6 support by the underlying components. Checking whether user input is a valid IPv4 address or rendering output under the assumption that an address is always an IPv4 address are typical examples for this class of limitations.

Connectivity Checks Some applications perform connectivity checks to determine whether Internet access is available by trying to connect to one or more well-known endpoints. If the connectivity check endpoints differ from the actual endpoints used by the application, this approach can lead to incorrect conclusions - especially in IPv6-only environments when connectivity checks are IPv4-only or in environments with strict network polices or split-tunnel VPNs. Applications should prefer implementing appropriate error handling for connectivity issues than relying on connectivity pre-checks.

Misbehaving Middle-Boxes In practice, many IPv6-related regressions uncovered during testing turn out to be caused by hidden components outside of the application developers' control. Middle-Boxes, e.g., firewalls, virus scanners, and intrusion detection systems, can break end-to-end tests in surprising ways, like terminating TLS sessions over IPv6 with certain extensions in the TLS client hello while correctly passing the same flow over IPv4.

Deployment Considerations Lab testing of applications for IPv6 compliance should always have the next step in mind: Deploying the application and providing the users with decent IPv6 support. Therefore, end-to-end tests, especially of cloud applications, should also keep deployment steps, prerequisites, and risks in mind. This section discusses some issues to keep in mind when planning and executing IPv6 testing.

Operational Scope & Software Lifecycle Depending on the application and deployment model, the timing of deploying IPv6 support may be in control of the users' organization, the developers' organization, or neither of them. Based on this setup, certain combinations of IPv6-enabled clients, servers, and infrastructure in between may or may not be excluded from consideration. Therefore, it may be necessary to add test cases for old software versions with known and already fixed bugs against newly IPv6-enabled servers. If regressions and service disruptions cannot be ruled out by the tests, a per-user or per-customer tenant opt-in/opt-out/roll-back scheme for the IPv6 enablement should be considered.

Allow & Deny Lists Application-level IP allow and deny lists pose a special challenge for deploying IPv6 in a cloud application. As users may already have IPv6 connectivity, adding IPv6 support to the server may cause clients to use IPv6 immediately. Having no allow list entry for the users' IPv6 addresses results in service disruptions. Happy Eyeballs as defined in does not solve the problem as allow list checks usually take place after the transport connection has already been established. To mitigate allow or deny lists causing service disruptions when enabling IPv6, support to include IPv6 addresses in allow and deny lists needs to be enabled way before rolling out IPv6 on the transport and communicated towards the users. To further limit the probability of service disruptions, generalizing Happy Eyeballs to re-try using IPv4 after certain error conditions should be evaluated.

Component and Service Reuse If components or cloud services can be reused in other products, special care needs to be taken when planning IPv6 deployment. The interaction contracts between the reusing parties and the service need to be checked whether IPv6 enablement of the services also affects the flows of these. Additional end-to-end tests, including the reusing parties, are recommended. This is often a recursive process.

Ownership of Software Components Sometimes IPv6 enablement requires touching components that are not actively maintained anymore. Be prepared for this and plan extra time or budget for updating or replacing these components.

Security Considerations The testing procedures described in this document do not create any new security implications. Some security-related issues that should be considered and ruled out by appropriate testing are discussed in .

IANA Considerations This document has no IANA actions.

References Normative References Energy Sciences Network Jisc Tachyon Dynamics This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of "known-local" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to- GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It introduces a requirement to implement Rule 5.5 of RFC 6724 and reduces the default precedence for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 precedence behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] Informative References Széchenyi István University The IPv6 Company University of New Hampshire, Interoperability Lab (UNH-IOL) QA Cafe This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. The IPv6 Company This document defines the terminology regarding the usage of expressions such as "IPv6-only" and "IPv6-Mostly", in order to avoid confusions when using them in IETF and other documents. The goal is that the reference to "IPv6-only" describes the actual native functionality being used, not the actual protocol support. Energy Sciences Network RIPE NCC Google This document discusses a deployment scenario called "an IPv6-mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). The proposed approach enables smooth and incremental transition from dual-stack to IPv6-only network by allowing IPv6-capable devices to remain IPv6-only while the network is seamlessly supplying IPv4 to those that require it. Google Google Cloudflare 464XLAT defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution involves two functional elements: a provider-side translator (PLAT) and a customer-side translator (CLAT). This document updates the 464XLAT specification (RFC6877) and Requirements for IPv6 Customer Edge Routers (RFC8585) by further defining CLAT node behavior and IPv6 Customer Edge Routers to support IPv4-as-a-Service by providing recommendations for node developers on enabling and disabling CLAT. n.d. n.d. n.d. n.d. n.d. n.d. This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the Interactive Connectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE. This document obsoletes RFCs 5766 and 6156. If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK] When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK] Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901. This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture specification (RFC 4007), should be entered into a user interface. This document obsoletes RFC 6874 and updates RFCs 4007, 7622, and 8089. DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK] This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK] This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS-TRACK]

Acknowledgments Thanks to Andrew Yourtchenko, Axel Schemberg, Brian E Carpenter, Holger Füßler, Jeremy Duncan, Jordi Palet, Michael Perscheid, Michael Richardson, Nathan Sherrard, Sulabh Soneji, and Tommy Jensen for the discussions, the input, and all contribution.